Frida and App Integrity detection not working as expected #193
-
|
Describe the bug To Reproduce From Mobile App Side
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);
}
}
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,
);
},
);
From Pentest Side
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); };
});
Expected behavior
Please complete the following information:
** Tools Used:**
|
Beta Was this translation helpful? Give feedback.
Replies: 20 comments
-
|
Hello. Thanks for raising this issue. We are looking into it. |
Beta Was this translation helpful? Give feedback.
-
|
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 If this is happening, then using |
Beta Was this translation helpful? Give feedback.
-
It can be true, but documentation mentioned that you can use in this way. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
Any update about it? |
Beta Was this translation helpful? Give feedback.
-
|
We investigated the issue and found a solution. We believe the countermeasure could be rolled out in the next freeRASP release. |
Beta Was this translation helpful? Give feedback.
-
|
any update sir? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Helloo.. Any update on this? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @rakesh0689, The disadvantage of freeRASP is the public interface used to inform the app about detected threats. If the pen testers do some analysis of your application, they will probably find the code where the freeRASP is executed or the threat callbacks are handled. However, this doesn't mean that using freeRASP is pointless. Our goal is that freeRASP can withstand various types of automated attacks. For example, if you used only the reFlutter to resign the APK (without the additional analysis and modification of the app), our library should detect it. The same applies to the predefined Frida scripts that are publicly available, and they should be detected. Regarding the slower detection speeds. As @syakymchuk already mentioned, the techniques are still evolving. We'll look at the sudden performance drop of the root/hook detection in the latest versions, and let you know. Best regards, |
Beta Was this translation helpful? Give feedback.
-
|
Ok @xprikryl2 Thank you for letting me know the details. Please do look into the increase in detection time. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @rakesh0689 , I tested the current version, past version and monitoring data. The experienced slowdown may happen during reverse engineering or under conditions described in this wiki page: https://github.com/talsec/Free-RASP-Community/wiki/Callback-Delay,-Telemetry-Impact,-and-Threat-Scanning-Completion-Status We expect improvements in the upcoming version that will incorporate new cloud infrastructure. Yet, the limitations of freeRASP vs. commercial version stay the same (as @syakymchuk written here: #103 (comment) ), esp. "Network calls for the data collection are performed before the callbacks are invoked.". This means under bad network conditions; callbacks may take some time to be delivered as freeRASP first try to finish the data collection. Best Regards, |
Beta Was this translation helpful? Give feedback.
-
|
Hello! |
Beta Was this translation helpful? Give feedback.
-
|
so you guys basically said, "nah we we aint gon fix this, if you want this feature, then upgrade to paid plan or f off" |
Beta Was this translation helpful? Give feedback.
-
Not exactly. The security limitation of freeRASP (bypass possibility) will stay, but latency due to bad_network related UX problems should be solved. |
Beta Was this translation helpful? Give feedback.
-
|
@thisisyusub can u share your frida js file please to know which script u used to bybass this , and is the problem still or they fixed in next releases ? ty . |
Beta Was this translation helpful? Give feedback.
-
|
Still not fixed on 6.9.0 |
Beta Was this translation helpful? Give feedback.
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, …