Frida and App Integrity detection not working as expected

[thisisyusub]

Describe the bug
We have released and configures security with freerasp. But our pentester team investigated that, in the following scenerio, it is not working as expected to catch jailbreak, frida and app integrity check.

To Reproduce

From Mobile App Side

1. Create App Protection Service like following:

class InAppProtectionService {
  InAppProtectionService();

  Future<void> init() async {
    final config = TalsecConfig(
      // For Android
      isProd: kReleaseMode,
      androidConfig: AndroidConfig(
        packageName: 'az.azerconnect.inside',
        signingCertHashes: [
          'base64 from sha256 from Google Play Console',
        ],
      ),

      // For iOS
      iosConfig: IOSConfig(
        bundleIds: ['az.azerconnect.inside'],
        teamId: 'Team ID from App Store Connect',
      ),

      // Common email for Alerts and Reports
      watcherMail: 'any email',
    );

    final callback = ThreatCallback(
      onAppIntegrity: () => exit(0),
      onDebug: () => exit(0),
      onPrivilegedAccess: () => exit(0),
      onSimulator: () => exit(0),
      onUnofficialStore: () => exit(0),
      onHooks: () => exit(0),
    );

    Talsec.instance.attachListener(callback);
    await Talsec.instance.start(config);
  }
}

---

2. Start it in the main.dart file:

runZonedGuarded<Future<void>>(
    () async {
      WidgetsFlutterBinding.ensureInitialized();

      final appProtectionService = InAppProtectionService();
      await appProtectionService.init();

      /// initializes [Firebase] for application
      await Firebase.initializeApp(
        options: DefaultFirebaseOptions.currentPlatform,
      );
      await AppStartupWrapper.initialize(environment, overrides);
    },
    (error, stack) async {
      return FirebaseCrashlytics.instance.recordError(
        error,
        stack,
        fatal: true,
      );
    },
  );

3. build.gradle file if it is interested:

---

4. Build app for android with the following command:

flutter build apk --obfuscate --split-debug-info=obfuscate/symbols --build-name=1.14.1 --build-number=60

From Pentest Side

1. Download the app from Play Store (1.14.1)
   https://play.google.com/store/apps/details?id=az.azerconnect.inside

---

2. Use “reflutter” tool to modify APK. In order to monitor the app traffic, select first option and enter your Burp Suite IP.

reflutter app.apk

---

3. Sign modified APK with “uber-apk-signer” tool.

java -jar uber-apk-signer-1.2.1.jar --apks inside_modified.apk

---

4. Install signed APK to the device.
   adb install inside_modified-aligned-debugSigned.apk

---

6. When the app is launched, it will crash instantly. To prevent that use following Frida script.

Java.perform(function() {
let C7508g = Java.use("s1.g"); C7508g["$init"].implementation = function(z, z2, z3) {
console.log(`C7508g.$init is called: z=${z}, z2=${z2}, z3=${z3}`);
this["$init"](true, false, false); };
});

---

7. Run the app using Frida script.

8. App will be launched successfully. Tap the “Skip” button.

---

9. Enter an email and a password.

---

10. Login request will be captured successfully.

Expected behavior
After all these processes, it should detect if app:

• runs on simulator, emulator, rooted device or not
• if it is hooked with Frida
• if this app is installed from Play Store or not (integrity check)

Please complete the following information:

• OS version: Android 11
• Version of freeRASP: 6.4.0

** Tools Used:**

• Reflutter 0.7.7
• Frida 15.2.2
• Uber APK Signer 1.2.1
• Burp Suite v2023.12.1.5
• Genymotion 3.6.0

[yardexx]

Hello.

Thanks for raising this issue. We are looking into it.

[cbarlow26]

Hi,

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

If this is happening, then using isProd: kReleaseMode would bypass all the release level callbacks like onAppIntegrity. Maybe try isProd: true and retest?

[thisisyusub]

Hi,

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

If this is happening, then using isProd: kReleaseMode would bypass all the release level callbacks like onAppIntegrity. Maybe try isProd: true and retest?

It can be true, but documentation mentioned that you can use in this way.

[yardexx]

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

My (educated) guess is that Frida hooks Talsec Android SDK which is implemented in a plugin. We are currently investigating that.

We generally recommend using isProd: true because it ensures that production mode is true even if the attacker messes around with Flutter SDK constants.

[thisisyusub]

Any update about it?

[SirionRazzer]

We investigated the issue and found a solution. We believe the countermeasure could be rolled out in the next freeRASP release.
Thank you for your help!

[dragongesa]

any update sir?

[martinzigrai]

Hello,

We've identified the issue and we're currently brainstorming about the possible solutions. The hooked class is responsible for the internal notifications, and we can harden it so it's not bypassable by the script above. However, it won't fix the bigger issue that is present in freeRASP.

The major disadvantage of the freeRASP is the public API that is used to notify the application about detected threats. If the attacker/pen. testing team is trying to focus on the protection itself (freeRASP library); after some time, they will find the single point of failure -> the notification threat listener (onHookDetected, onDebuggerDetected, ...). We can check the freeRASP's execution state, but if we discover that it's compromised, we are expected to notify the application using that threat listener.

This issue could be resolved by adding some automatic "app crash" mechanisms into the freeRASP, but we are reluctant to do this as it could cause crashes that are not transparent to the developers (as they lack access to the audit logs/reporting).

We'll add protection against this type of hook script in future release, but if you require a more robust solution to protect your application, please refer to our business solution (Business RASP+) and its advantages.

[rakesh0689]

Helloo.. Any update on this?
In my case Even after simply refluttering the apk and signing the refluttered apk using ubersigner the pen.testing team is able to open the app without using a frida scripts i believe. I have asked for confirmation as well regarding the same. I am using isProd : true in my app too.

[syakymchuk]

Hello @rakesh0689,

I let the team respond on this. I just wanted to confirm that freeRASP is not designed to sustain professional pentesting. The Commercial Version is designed for this. freeRASP will always have intentional architecture restrictions and Fair Usage Policy limitations.

Sergiy Yakymchuk
Talsec Co-founder

[rakesh0689]

Hello @syakymchuk,

See if freeRASP will always have intentional architecture restrictions - meaning it does not withstand even simple Pen Testing then it should be mentioned somewhere right. We had confidence that freeRasp will be our first line of defence that's why we added it to our production application as well. Had we known this earlier we would not have put our application at risk.
This issue is along with freeRasp not detecting Root & Hooking immediately as mentioned in other problems (bugs) puts our application at serious help. Kindly provide us with a way to improve the detection speed. Earlier builds like 5.0 or so didn't have this issue, i believe. I understand free version will not be similar to the paid one but that does not mean basic functionalities also needs to be restricted right? Kindly help.

[syakymchuk]

Hello @rakesh0689,

We try to be as transparent as possible with our community. The limitations of freeRASP vs. Business plans are clearly outlined here. We will consider making it more explicit and visible to avoid confusion. Thank you for drawing attention to the topic.

We don't consider this bypass method using hooking frameworks trivial. The business version is resilient to this, but freeRASP is not. It may be improved in the future, but business version improvements, SLAs, and commitments will go first.

The detection speed is always a matter of compromise between accuracy and performance. In the Business version, you can adjust the balance by configuration. Since rooting techniques evolve, the detection may take longer; in freeRASP, it works in an async way. Some improvements are planned for freeRASP here too. Stay tuned to get it as soon as available (Get updates form).

If this limitation impacts the business and has negative consequences, please contact the business team, and we will try to find the right business-grade solution for you.