How to Hack & Protect Flutter Apps — Steal Firebase Auth token and attack the API. (Pt. 3/3)
Last updated
Last updated
Company
General Terms and ConditionsJWT Token, MiTM Attacks and API Protection. Keep them properly protected and don’t put your enterprise at risk.
Part 1 (link) ↓
Disassemble app.
Extract its secrets.
Part 2 (link) ↓
Make a fake clone.
Check every transmitted JSON.
Inject code.
Part 3 (this article) ↓
Steal authentication tokens.
and attack the API.
A token is a piece of data that represents a specific identity or authorization. There are different types of tokens, including authentication tokens, which are used to authenticate a user’s identity, and bearer tokens, which grant access to a protected resource.
JWT, or JSON web tokens, are types of tokens used for authenticating and authorizing users. These tokens are encoded and signed, allowing the server to verify their authenticity. However, JWT tokens can be vulnerable to certain attacks, such as weak token signing and token tampering.
Weak tokens are tokens that have been compromised or are otherwise insecure. This can include tokens with weak or easily guessable signing keys, or tokens that have been stolen or otherwise obtained by an attacker. These weak tokens can be used to gain unauthorized access to a system or a protected resource.
The JWT standard allows the non-use of an algorithm (”alg”:”none”) to sign the token. This is of course a very bad practice. A user could change his rights on the fly (from “role”: “user” to “role”: “admin”), without any control by the server. In the same way, if the configuration carried out at the server level accepts different algorithms and the “none” variable, which consists of not having cryptographic functions, it will be possible for an attacker to bypass the integrity verification function to access the data of other users or even of the admin. This can be mitigated by choosing a reliable algorithm (SHA256) and force server to always check algorithm, and therefore reject the “none” variable.
Firebase Authentication is Flutter Apps’ most favorable authentication service. It allows developers to easily integrate user authentication into their applications using a variety of authentication methods, such as email and password, phone number, or social media accounts like Google, Facebook, and Twitter.
When a user signs up for an account using Firebase Authentication, the service generates an authentication token that is associated with the user’s account. This token is then stored on the user’s device and is used to verify their identity whenever they access the application.
When the user attempts to log in to the application, the authentication token is sent to the Firebase Authentication server, where it is verified and then passed back to the application. If the token is valid, the user is granted access to the application.
Now, if you’ve read the previous section carefully, you already know what we are after:
This token is then stored on the user’s device…
I want to emphasize that storing this token is a completely appropriate solution assuming the device’s sandbox and other security measures are intact.
This hello-world Flutter app is connected to Firebase Authentication. A few widgets, some copy-pasting from the Firebase tutorial, and it was up and running:
Once I registered my new account, I checked the account exists as well in Authentication Dashboard:
Everything works well, I am signed in
Sorry, I won’t show you any zero-day vulnerability. I assume there is a vulnerable system at play or a malicious 3rd party library (yes, 3rd party dependencies can interfere with app’s data and more), which will steal data from within your application.
Locate the app’s data directory /shared_prefs
, which contains a file named com.google.firebase.auth(…)
.
The file has the following content:
I moved the content to my computer for easier manipulation. The highlighted text is Firebase Authentication JWT:
TIP: You can use fancy JWT viewer — jwt.io:
And here is the data:
An attacker could misuse this token for an impersonation attack. But to be able to make such an attack, it’s necessary to know the API. Let’s explore the API of the Flutter app.
An API attack is a type of cyberattack in which an attacker exploits vulnerabilities in an API in order to gain unauthorized access to sensitive data or systems.
Here are some examples of how a reverse engineer might carry out an API attack:
Sniffing: The attacker captures network traffic containing API requests and responses in order to extract sensitive information such as passwords or access tokens. This can be done using tools like Wireshark or Burp Suite.
Injection: The attacker modifies the API request in order to inject malicious code into the system. This can be done using techniques like SQL injection or cross-site scripting (XSS).
Tampering: The attacker modifies the API request in order to alter the data being transmitted, such as changing the value of a transaction or account balance.
Replay: The attacker captures a valid API request and then replays it multiple times in order to cause a denial of service (DoS) attack or gain unauthorized access to the system.
These are just a few examples of API attacks that a reverse engineer might carry out.
To attack the API of a mobile app, a reverse engineer would need to first identify the API and its associated vulnerabilities. This can typically be done by using a tool to intercept network traffic from the mobile app and analyzing the requests and responses to and from the API.
Once the API has been identified, the reverse engineer can attempt to exploit any vulnerabilities that are found. For example, if the API is not properly validated or sanitized, the reverse engineer could try injecting malicious code into the request in order to gain unauthorized access to the system or steal sensitive data.
Other tactics that might be used in an API attack on a mobile app include tampering with requests in order to alter data, capturing and replaying requests in order to cause a denial of service (DoS) attack, and sniffing network traffic to extract sensitive information.
strings — You can use strings
command available in many Linux distros to gather string resources from any Flutter app:
$ strings my-flutter-app.apk | grep http
to gather URLs
GraphQL architecture — You can find GraphQL queries in the app’s binary
REST architecture — You can use strings
or Burp Proxy (MITM) again. Common APIs can be found here. The web service may also have it’s OpenAPI (Swagger) documentation available.
I decided to end this article here as there is a plethora of API hacking tutorials: https://duckduckgo.com/?q=api+hacking+burp+postman
Check of your Firebase is properly configured: https://github.com/MuhammadKhizerJaved/Insecure-Firebase-Exploit
Glance over the Resources section of this article and check out one of the provided cheatsheets (the most relevant to your app)
IMPORTANT: Majority of network attacks (impersonation, malicious scripts, botnets, JWT stealing, etc.) can be defeated by Talsec’s unique technology AppiCrypt. Check it out!
Thank you for reading the third part of this guide. I hope the information I’ve provided has been useful and informative! Thank you again for joining me on this journey.
written by Tomáš Soukal, Security Consultant at Talsec
It would be impossible to provide tutorial for every possible mobile app + web service architecture. Hence, I compiled useful list of OWASP and other resources about web application security. Use the list below to find quickly technologies and guides related to your use-case.
Firebase security checklist
Misconfiguration of Firebase — world readable https://xyz.firebaseio.com/.json
Exploit tool for this vulnerability:
A simple Python Exploit to Write Data to Insecure/vulnerable firebase databases! Commonly found inside Mobile Apps. If the owner of the app have set the security rules as true for both “read” & “write” an attacker can probably dump database and write his own data to firebase db. Control Access with Custom Claims and Security Rules | Firebase Authentication
Verify ID Tokens | Firebase Authentication