Android Telephony Flaw: How Guest Users Can Hijack SIM Settings

What Happened

Google's Android Telephony system contains a missing permission check that allows guest users to change preferred SIM settings without authorization. Tracked as CVE-2023-21373, this vulnerability enables local privilege escalation on devices with multiple SIM slots—a common scenario across India where dual-SIM phones dominate the market.

The flaw exists in the Telephony framework's permission validation logic. When a guest user (or any unprivileged local process) attempts to modify SIM preferences, the system fails to verify whether the caller has the required permissions. This means an attacker with local access to a device—either physically or through a compromised app—can switch the default SIM used for calls, SMS, and mobile data without triggering any permission prompts or requiring elevated privileges.

What makes this particularly dangerous is that no user interaction is required. A malicious app running in the background, or an attacker with brief physical access, can silently reconfigure which SIM is active. For businesses using Android devices for critical communications—particularly in banking, healthcare, and government sectors—this opens a direct path to SIM swapping attacks, credential interception, and business continuity disruption.

Why This Matters for Indian Businesses

In my years building enterprise systems for Fortune 500 companies, I've seen how often mobile security is treated as an afterthought. But in India's context, this vulnerability has three critical implications:

1. DPDP Act Compliance Risk India's Digital Personal Data Protection Act, 2023 requires organizations to implement "reasonable security practices" for personal data. A compromised SIM means attackers can intercept OTPs, two-factor authentication codes, and sensitive SMS communications containing personal data. If your organization processes customer data on Android devices, a successful SIM hijack could constitute a data breach under DPDP—triggering mandatory breach notification within 72 hours and potential penalties up to ₹250 crore.

2. CERT-In Reporting Obligation Indian organizations must report security incidents to CERT-In (Indian Computer Emergency Response Team) within 6 hours of discovery. A widespread exploitation of CVE-2023-21373 across your Android fleet could trigger this obligation. Organizations that fail to report face penalties under the Information Technology Act, 2000.

3. Dual-SIM Dependency in India Unlike Western markets, dual-SIM phones represent over 60% of smartphone shipments in India. This vulnerability directly impacts the Indian market's most common device configuration. Attackers can exploit this to:

1. Intercept banking OTPs by switching to attacker-controlled SIM
2. Perform SIM swapping attacks for social engineering
3. Redirect corporate communications to competitor infrastructure
4. Disable emergency communication during critical incidents

Technical Breakdown

How the Attack Works

Android's Telephony framework manages SIM slot preferences through the TelephonyManager and SubscriptionManager classes. These components store which SIM is preferred for voice calls, SMS, and data. The vulnerability exists because permission checks are missing at the API boundary.

The Permission Bypass

Normally, modifying system settings requires the MODIFY_PHONE_STATE permission. Here's what the vulnerable code path looks like:

// Vulnerable code in Telephony framework (simplified)
public void setPreferredDataSubscriptionId(int subId) {
    // Missing: checkPermission("android.permission.MODIFY_PHONE_STATE")
    
    // Directly modifies the preferred SIM without validation
    Settings.Global.putInt(mContext.getContentResolver(),
        Settings.Global.MULTI_SIM_DATA_CALL_SUBSCRIPTION,
        subId);
}

An attacker doesn't need to declare MODIFY_PHONE_STATE in their manifest. They can call this method directly:

// Attacker's code
SubscriptionManager subManager = SubscriptionManager.from(context);
subManager.setPreferredDataSubscriptionId(attackerControlledSimSlot);
// Success — no permission error, no user prompt

Real-World Attack Scenario

Imagine a financial services company where employees use Android devices to access banking APIs. An attacker distributes a trojanized "productivity app" that includes this exploit:

1. Initial Compromise: Employee downloads a fake "Office Suite" app from third-party store
2. Silent Exploitation: App calls the vulnerable Telephony API to switch the preferred SIM
3. OTP Interception: When the employee logs into their banking portal, the OTP is sent to the attacker's SIM (now the "preferred" one in the device's routing logic)
4. Account Takeover: Attacker uses the intercepted OTP to access banking credentials
5. Lateral Movement: Attacker gains access to corporate banking systems

How to Protect Your Business

Defense Layers

Immediate Actions (This Week)

Step 1: Inventory Your Android Fleet

If you're using Android devices for business, create an inventory:

# For enterprise MDM (Mobile Device Management) administrators
# Export device list with Android versions
adb devices -l | grep -E "model|device"

# Or use your MDM console (Google Workspace, Microsoft Intune, etc.)
# Filter devices running Android < 12 (most vulnerable)

Step 2: Push Security Updates

Google released patches in the April 2023 Android Security Bulletin. If you manage devices via MDM:

# Force update check on managed devices
# In Google Workspace:
# Admin Console → Device Management → Android → Push Updates

# In Microsoft Intune:
# Devices → Android devices → Device compliance → Create policy

Step 3: Audit App Permissions

Review which apps have access to phone state:

# On each Android device, check:
# Settings → Apps & Notifications → Permissions → Phone
# Remove any third-party apps that don't need phone access

Long-Term Hardening

1. Implement Mobile Device Management (MDM)

Deploy MDM to enforce:

1. Mandatory security updates within 30 days of release
2. App allowlist (only approved apps can be installed)
3. Disable guest user accounts on shared devices
4. Monitor for unusual Telephony API calls

Migrate from SMS OTP to:

1. FIDO2 security keys (hardware-backed)
2. Biometric + passkey combinations
3. Push notifications for approval (harder to intercept)

// Example: Biometric + Passkey auth (Android 12+)
BiometricPrompt biometricPrompt = new BiometricPrompt(
    activity,
    executor,
    new BiometricPrompt.AuthenticationCallback() {
        @Override
        public void onAuthenticationSucceeded(
            @NonNull BiometricPrompt.AuthenticationResult result) {
            // Verify passkey instead of SMS OTP
            verifyPasskey(result.getAuthenticationResult());
        }
    }
);

3. Monitor for SIM Changes

If you have an in-house security team, implement monitoring:

// Monitor SIM state changes
BroadcastReceiver simStateMonitor = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals(TelephonyManager.ACTION_SIM_STATE_CHANGED)) {
            String simState = intent.getStringExtra(TelephonyManager.EXTRA_SIM_STATE);
            // Log unexpected SIM changes
            if (simState.equals(TelephonyManager.SIM_STATE_READY)) {
                logSecurityEvent("SIM_STATE_CHANGED", "POTENTIAL_ATTACK");
            }
        }
    }
};

How Bachao.AI Detects This

This is exactly why I built Bachao.AI — to make enterprise-grade security accessible to Indian SMBs without the enterprise annual security team budget.

Protect your business with Bachao.AI — India's automated vulnerability assessment and penetration testing platform, built by Dhisattva AI Pvt Ltd. Get a comprehensive security scan of your web applications and infrastructure. Visit Bachao.AI to get started.

Why This Matters in Your Security Stack

When I architected security for large enterprises, we always treated mobile as a separate threat surface. But most Indian SMBs don't have dedicated mobile security teams. That's the gap Bachao.AI fills.

If you're running:

1. Android apps that handle authentication
2. Business communications on employee phones
3. Banking or fintech operations
4. Healthcare or legal services with sensitive data

Action Plan

This Week:

1. Inventory Android devices in your organization
2. Push latest security updates
3. Audit app permissions (remove unnecessary phone access)

1. Deploy Mobile Device Management (MDM)
2. Implement passwordless authentication
3. Run a VAPT scan on your Android apps

1. Migrate from SMS OTP to biometric + passkey
2. Implement SIM change monitoring
3. Train employees on app security risks

Book Your Free Android Security Scan →

We'll audit your apps, devices, and authentication flows for CVE-2023-21373 and 200+ other Android vulnerabilities. Takes 30 minutes, no credit card required.

1. Frequently Asked Questions

Why is this especially relevant in the Indian context? India has one of the world's highest dual-SIM device penetration rates. Many Indian SMB employees use one SIM for personal use and one for work on the same device. An attacker exploiting CVE-2023-21373 could redirect work calls and SMS — including OTP codes — through a different SIM, enabling account takeover and bypassing SMS-based two-factor authentication.

How can Indian SMBs mitigate this risk? Apply the October 2023 Android security patch immediately. Migrate away from SMS-based OTP authentication for business-critical systems in favor of app-based authenticators or hardware keys. Implement MDM to prevent guest account access on corporate devices and audit SIM change policies.

Originally reported by NIST NVD*

Written by Shouvik Mukherjee, Founder of Bachao.AI. Follow me on LinkedIn for daily cybersecurity insights for Indian businesses.