Author: admin

Introduction

The su (substitute user) binary is a cornerstone of privilege escalation on Android devices. It allows a user to execute commands with the privileges of another user, most notably the root user. While legitimate rooting solutions leverage a controlled su binary, malicious actors can exploit, replace, or manipulate this binary to gain unauthorized root access, bypass security controls, and compromise the device. For security auditors, penetration testers, and developers concerned with device integrity, mastering the detection of su binary exploits is paramount. This article delves into expert-level tools and techniques for identifying compromised su binaries and their associated activities.

Understanding the Legitimate `su` Binary on Android

A legitimate `su` binary, typically installed by rooting solutions like Magisk or SuperSU, is designed to manage and grant root permissions. It resides in a system-privileged location and adheres to strict permission models. Its primary function is to interpret requests for root access, consult a policy (e.g., a whitelist of apps or user confirmation), and then execute the requested command with elevated privileges.

• Typical Locations: /system/bin/su, /system/xbin/su, or more recently, within a Magisk-mounted overlay (/sbin/.magisk/mirror/system/bin/su) to avoid direct system partition modification.
• Permissions: It usually has setuid (SUID) permissions (e.g., -rwsr-sr-x or -rwxr-xr-x with specific ownership), allowing it to run with the effective UID of its owner (root) regardless of the calling user.
• Owner/Group: Typically owned by root:root.

Deviations from these expected characteristics are often the first indicators of a compromise.

Common `su` Binary Exploit Vectors

Attackers employ various methods to weaponize or exploit the su binary:

1. Malicious `su` Replacement or Injection

An attacker might replace the legitimate su binary with a malicious version that grants root access unconditionally, logs activities, or executes arbitrary code. This can happen through vulnerabilities in the Android system, custom recovery installations, or pre-rooted devices with backdoored firmware.

2. Permission Misconfigurations

Even if the su binary itself is clean, incorrect file permissions or ownership can allow non-privileged users to modify it or bypass its intended security policy.

3. Vulnerabilities in `su` Implementations

Specific versions of su binaries (especially older or poorly maintained ones) might contain vulnerabilities (e.g., buffer overflows, logic flaws) that can be exploited to gain root without proper authorization, even if the binary appears legitimate.

Advanced Detection Techniques

Detecting a compromised su binary requires a multi-faceted approach, combining static and dynamic analysis with robust integrity checks.

1. File System Integrity Checks

This is the foundational step. We examine the su binary’s presence, permissions, and cryptographic hash.

a. Location and Permissions Verification

Connect to the device via ADB and inspect the common su paths:

adb shell "ls -l /system/bin/su; ls -l /system/xbin/su; ls -l /sbin/.magisk/mirror/system/bin/su"

Expected Output (Example for Magisk-rooted device):

/system/bin/su: No such file or directory # Or a symbolic link to /sbin/.magisk/su/bin/su if MagiskHide is off, etc. 

/system/xbin/su: No such file or directory

lrwxrwxrwx 1 root root 22 2023-10-26 10:00 /sbin/.magisk/mirror/system/bin/su -> ../../.magisk/su/bin/su

Look for:
– Unexpected presence of su in /system/bin or /system/xbin if a systemless root (like Magisk) is expected.
– Incorrect ownership (should be root:root).
– Incorrect permissions (e.g., lack of SUID bit, or overly permissive write access for non-root users).

b. Cryptographic Hashing and Comparison

Calculate the SHA256 hash of the su binary and compare it against known good hashes for specific root solutions and versions, or against a baseline from a clean device. Be aware that Magisk frequently updates, so hashes change.

adb shell sha256sum /sbin/.magisk/su/bin/su

Example Output:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y4z5a6b7c8d9e0f1 /sbin/.magisk/su/bin/su

Manual comparison against official releases or trusted sources is crucial. Any mismatch indicates tampering.

2. Process Monitoring and Analysis

An exploited su binary will likely be invoked. Monitoring active processes can reveal suspicious activity.

a. Identifying `su` Invocations

Use ps to list processes. Look for unusual processes running as root, or unexpected applications invoking su.

adb shell ps -ef | grep su

Example Output:

root      2040     1 0 10:00 ?        00:00:00 /sbin/.magisk/su/bin/su --daemon

u0_a123   5678    2040 0 10:05 ?        00:00:00 /sbin/.magisk/su/bin/su -c id

A long-running su --daemon is normal for Magisk. However, frequent, unexpected invocations by unknown apps, or su processes running under a non-root UID that don’t immediately exit, warrant investigation.

b. Real-time Process Monitoring with `top` or `htop`

For live monitoring, `top` provides a dynamic view. In a rooted environment, `htop` (if installed) offers a more user-friendly interface.

adb shell top

Look for any unfamiliar processes running with a UID of 0 (root).

3. Dynamic Analysis with Runtime Hooks (Frida)

Frida is a powerful dynamic instrumentation toolkit that can hook into running processes and observe or modify their behavior. This is invaluable for detecting sophisticated `su` exploits that might try to hide their traces.

a. Hooking `execve` for `su` Calls

We can hook the execve syscall to log every attempt to execute a new program, specifically filtering for su. This helps detect unexpected calls to the su binary.

// frida_su_monitor.js 

Java.perform(function() { 

  Interceptor.attach(Module.findExportByName(null, 'execve'), { 

    onEnter: function(args) { 

      this.path = args[0].readUtf8String(); 

      if (this.path && this.path.includes('/su')) { 

        console.log('[*] execve called: ' + this.path); 

        console.log('    Arguments:'); 

        var arg_ptr = args[1]; 

        var i = 0; 

        var arg; 

        while ((arg = arg_ptr.add(i * Process.pointerSize).readPointer()).isNull() === false) { 

          console.log('        ' + i + ': ' + arg.readUtf8String()); 

          i++; 

        } 

      } 

    } 

  }); 

  console.log('[*] Monitoring execve calls for 'su' binary...'); 

});

To run this:

frida -U -l frida_su_monitor.js --no-pause system_server

This script will log any `execve` calls involving paths containing `/su`, offering insights into which processes are attempting to gain root.

4. Static Analysis and Reverse Engineering

For deeply embedded exploits or custom `su` binaries, static analysis using tools like Ghidra or IDA Pro is essential. This involves pulling the `su` binary from the device and disassembling it.

a. Binary Disassembly and Code Review

What to look for:

• Unexpected Network Connections: Does the `su` binary attempt to connect to remote servers, exfiltrate data, or download additional payloads?
• Obfuscated Code: Highly obfuscated sections might indicate malicious intent.
• Unusual Library Dependencies: Links to libraries not typically associated with `su` (e.g., networking, encryption).
• Hardcoded Credentials or Backdoors: Specific logic that bypasses normal permission checks for certain UIDs or package names.
• System Call Monitoring Evasion: Attempts to disable logging or anti-tampering mechanisms.

Steps:
1. Pull the `su` binary: adb pull /sbin/.magisk/su/bin/su su_binary
2. Load su_binary into Ghidra or IDA Pro.
3. Analyze the control flow graph, identify key functions (e.g., `main`, `setuid`, `execve`), and look for anomalies.

5. Log Analysis

Android’s logcat can provide valuable forensic data, including errors, security policy violations, and `su` related activities.

adb logcat | grep -i "su|root|setuid|exec"

Look for frequent permission denied errors when `su` is invoked, or unusual messages from applications attempting to gain root privileges. Root management apps also often log their `su` grant/deny decisions.

Automated Tools and Frameworks

While manual techniques offer deep insight, automated tools can aid in initial detection:

• MobSF (Mobile Security Framework): Performs static and dynamic analysis of Android applications, including root detection checks and binary analysis.
• Android SafetyNet Attestation: While not directly detecting `su` exploits, it verifies device integrity, which can be an indirect indicator of rooting or tampering.
• RootBeer / RootBeerFresh: Open-source libraries for Android apps to detect various rooting methods, including `su` binary checks, though they can be bypassed.

Mitigation and Prevention Strategies

To prevent `su` binary exploits, implement these best practices:

• Verified Boot and Bootloader Security: Ensure the bootloader is locked or uses verified boot to prevent tampering with system partitions.
• Regular OS Updates: Apply security patches promptly to fix vulnerabilities that attackers might use to inject malicious `su` binaries.
• Application Sandboxing: Restrict app permissions to minimize the attack surface.
• Monitor Device Integrity: Regularly perform integrity checks as described above, especially on critical devices.

Conclusion

Detecting compromised su binaries is a critical skill in Android security auditing. By combining rigorous file system integrity checks, real-time process monitoring, dynamic analysis with tools like Frida, and in-depth static analysis, security professionals can effectively uncover even sophisticated `su` related exploits. Staying vigilant and applying these expert-level techniques are key to maintaining the integrity and security of Android devices in a world of evolving threats.