Last updated
OWASP Mobile Application Security guides all phases of mobile app development and testing. The Verification Standard and the Testing Guide will provide you with a security standard and a baseline for mobile app security verification curated by a community dedicated to improving software security. Put in the right RASP suite to get the best passive and active security mix.
Part 1 (link) ↓
Disassemble app.
Extract its secrets.
Part 2 (this article) ↓
Make a fake clone.
Check every transmitted JSON.
Inject code.
Part 3 (link) ↓
Steal authentication tokens.
and attack the API.
To create a fake or “cloned” version of an Android app using apktool, you first need to decompile the original app using the apktool d command. This would extract the contents of the app, including its resources, manifest file, and compiled code, into a directory on your computer. Next, you need to make the desired modifications to the app, such as changing its name, icon, or functionality. Once the modifications are complete, you can use the apktool b command to rebuild the app into a new APK file. This APK file would contain the modified version of the app, which you could then install on an Android device.
While you could fiddle with Flutter’s binary libapp.so file, I would just inject code into MainActivity.smali file, which is present in every Flutter Android app. The code used in this file is called smali. You can modify it as you wish. This can be misused to add a custom Activity, paywall, ads, or for credential harvesting. An adversary may be able to load native library containing reusable malware code. In my experience, the injection of hidden malicious native code is actually quite common.
This is the MainActivy.smali file in a stock Flutter app after being disassembled with apktool:
Example 1: Hello World
This code is a simple ‘Hello, world!’ string written into log.
Example 2: Open browser intent to a malicious website
This code will prompt a user to open the adversary-controlled phishing page.
Let’s change the side and assume you want to protect your app against such attacks instead. I have great news! There is a standard for that. It’s called OWASP Mobile Application Security (OWASP MAS) which can guide you. It is a comprehensive guide for mobile app security with actionable solutions for many problems.
I should now advise you to visit the OWASP MAS using the link below. But it would also mean I would lose your attention. If you promise that you will return here, you can click it:
MAS Verification Standard (MASVS) will help you to understand something called security levels (L1 Standard Security, L2 Defense-in-Depth, R Resiliency). It will also introduce you to respective categories and their requirements:
MAS Testing Guide (MASTG) holds platform-specific detailed content about all security techniques. Unfortunately, it is targeted at iOS and Android devs and is less beneficial to Flutter devs.
MAS Checklist is a sheet used to check all requirements one by one to ensure nothing was left.
JSON attacks, also known as JSON injection, refer to a type of backend web application vulnerability that occurs when user-supplied data is passed through a JSON parser without proper validation or sanitization. This can allow an attacker to inject malicious code into the JSON data, which can then be executed by the application.
To make a JSON attack, an attacker would need to craft a malicious payload that is designed to exploit the vulnerability in the target application. This payload could be included in an HTTP request, hidden in a file, or delivered through some other means. Once the payload is delivered to the application, it would be parsed by the JSON parser and executed, potentially allowing the attacker to gain unauthorized access or perform other malicious actions.
To protect against these types of attacks, it’s important to implement proper input validation and sanitization, as well as keep backend web applications up to date with the latest security patches. Another method to mitigate the JSON injection attack is to ensure that API call comes from a legit client and not crafted by an attacker who may have valid authentication token. Talsec provides the AppiCrypt technology to verify client-side legitimacy and integrity. In comparison with the similar Firebase AppCheck technology the AppiCrypt can do this with every API call.
I will use the reFlutter tool to break into an app and intercept it’s JSONs. The hacked app will reveal the content of its network traffic in the Burp proxy.
I have chosen an arbitrary automotive app featured on the Flutter homepage. Just imagine that hackers would have discovered a vulnerability in such an app, allowing them to open the car’s trunk remotely. Such scenarios are actively researched nowadays and serve as a reminder of the importance of regularly updating software and maintaining strong security measures to protect against hackers.
Seeing the capabilities of this app makes me wonder what would happen if someone could exploit it. Remote unlock, car horn, remote cameras, car location and other super-sensitive operations can be invoked within this app.
To inspect traffic using the Burp Interceptor proxy, you first need to set up Burp Suite on your computer and configure your testing device to use the Burp proxy. Once Burp is set up, you can use the Interceptor tab to view and manage incoming and outgoing traffic. The Interceptor tab displays a list of requests and responses, along with details such as the URL, method, headers, and payload.
I downloaded the app from my testing device to my computer and reFluttered it:
At this moment, I am able to inspect every request, uncover hidden advertising campaigns, and so on. In general, this opens access to data like:
API architecture
Source URLs
HTTP headers
Bearer tokens
Transmitted data (i.e., JSON)
A plethora of threats can be solved by a potent runtime application self-protection (RASP) library. There are various free solutions, but I have chosen the freeRASP since it covers most areas, and I also contributed to this library.
Key features are the detection and prevention of root/jailbreak (e.g., unc0ver, check1rain), hooking framework (e.g., Frida, Shadow), untrusted installation method, and App/Device (un)binding.
Speaking of OWASP MAS levels, you would mostly be interested in RASP if your app should be compliant with R-level oriented on resiliency aspects. Actually, many devs integrate freeRASP as a future-proof solution to stay ahead even before their app truly needs R-level. This is something I am really proud of.
I prepared a small demo below showing freeRASP’s checks triggered on a rooted emulator. However, you can process the threat flags as you need. From my experience, the most common way is to show a dialog to warn the user about a tampered app or device and forbid any sensitive operations. I also wrote about freeRASP in this blogpost previously.
Find out which security level (e.g., L1+R) is recommended for your app: https://mas.owasp.org/MASVS/Intro/0x03-Using_the_MASVS/
Try out freeRASP to get fundamental RASP features into your app: https://pub.dev/packages/freerasp
Thank you for reading the second part of this guide. It’s always great to have an interested and engaged reader, and I appreciate your time and attention. I hope the information I’ve provided has been useful and informative! Thank you again for joining me on this journey.
Part 3 of this series will be available soon. Subscribe to Talsec and maybe try to crack-open some Flutter app in the meantime!
written by Tomáš Soukal, Security Consultant at Talsec
