How I Discovered a 0-Click Account Takeover (ATO) Vulnerability in a Flutter Application

Discovering an Account Takeover (ATO) vulnerability is always exciting, but finding a 0-click ATO? That’s a game-changer. In this article, I’ll walk you through how I identified this critical vulnerability during a recent penetration testing engagement for an Android Flutter application.

Before diving into the vulnerability details, let’s talk about a significant hurdle I encountered during this engagement: configuring the application to work with a proxy for traffic interception using Burp Suite.

I spent over four hours trying various methods to set up the proxy but kept hitting dead ends. Here’s what I tried:

ProxyDroid for global tunneling — No luck.Frida scripts to bypass SSL pinning — Still didn’t work.reFlutter — Again, no success.

Eventually, I found a solution: adding an override class in the application’s source code to enable a specific proxy to work with my Burp Suite configurations. Here’s the code I used:

Code to Add in “main.dart”

class MyHttpOverrides extends HttpOverrides {
@override
HttpClient createHttpClient(SecurityContext? context) {
if (Platform.isAndroid) {
return super.createHttpClient(context)..badCertificateCallback = (X509Certificate cert, String host, int port) => true;
}

return super.createHttpClient(context)
..findProxy = (uri) {
return "PROXY IP:PORT";
}
..badCertificateCallback = (X509Certificate cert, String host, int port) => true;
}
}

Modifying “main()":

HttpOverrides.global = MyHttpOverrides();

With this setup, I could run ProxyDroid and intercept the application’s traffic without needing an SSL pinning bypass.

This was a huge breakthrough and set the stage for uncovering the vulnerability.

Now, let’s dive into the vulnerability itself.

Exploring the Application’s Features

While reviewing the application’s features, I came across an interesting one: the update profile functionality. Here’s what I noticed:

The update profile feature allowed users to modify their name and address but not their phone number, as the phone number was being used as an identifier.Notice that the phone number was displayed, ending with “60”

Intercepting the Update Request

I sent an update request to change my name to “test” and intercepted the request using Burp Suite. The payload included the following parameters:

Interestingly, the application used the phone number as an email in the request.

Exploiting the Vulnerability

Here’s what I did:

I modified the emailparameter to another account’s phone number (e.g., changing “12345660” to “12345653”).I sent the request and intercepted the response.

To my surprise, the server responded with:

Confirming the Exploit

I refreshed my account page and confirmed that the changes had been successfully applied to the other user’s account. At this point, I realized I had discovered a 0-click ATO vulnerability. Without any user interaction, I could take over another user’s account by simply modifying the phone number in the update request.

This vulnerability is critical because:

It allows attackers to take over accounts without any interaction from the victim.It bypasses authentication and authorization mechanisms, compromising user data and application integrity.

Uncovering this 0-click ATO vulnerability highlights the importance of rigorous security testing in mobile applications. Developers must ensure proper validation and authentication for critical identifiers like phone numbers.

Have you faced similar challenges in your pentesting engagements? Let me know in the comments or share your thoughts. Together, we can make applications more secure!