Introduction

This article focuses on the exhaustive analysis of the communication layer of an Android mobile application for a smartwatch through network traffic interception and the manipulation of authentication and data flows. The relevance of this analysis lies in the detection of critical vulnerabilities that, while they may seem like minor implementation flaws, represent severe operational risks. The identified attack vectors range from failures in session and credential management (such as the absence of anti-brute force mechanisms) to deficiencies in business logic and data management, allowing unauthorized access to third-party information.

Analysis

1. Credential Management and Authentication

The analysis begins by opening the application and intercepting network communications using advanced tools such as Frida and a web proxy. It proceeds to evaluate both the user account creation process and anonymous access.

POST /watch/users/login/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/json; charset=UTF-8
Host: backend.application.tld

{"account":"<EMAIL_ADDRESS>","password":"<MD5_ENCODED_PASSWORD>","type":2}

A critical absence of protection mechanisms against brute force attacks was detected in the login process. The system allows a minimum of one hundred consecutive attempts without applying any lockout or throttling, facilitating credential guessing. Password exchange is performed via encrypted submission using the MD5 hash function. The use of MD5 is considered obsolete and extremely insecure for credential storage, as it is susceptible to collision and brute force attacks with relative ease.

The login mechanism not only fails authentication but also allows user enumeration. When making the login request, the server returns a structured response that explicitly confirms whether the username (email or UUID) exists in the system. This functionality allows an attacker to map the user database without needing to know credentials.

{  
    "code": 1009,  
    "data": "",  
    "message": "The user does not exist."  
}

2. Registration Flows

Standard registration requests only an email address and password. It is observed that, before registration, the application requests and generates a verification code sent to the user’s email address.

POST /watch/users/blvcode/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/x-www-form-urlencoded
Host: backend.application.tld

language=es&smsType=1&title=Application&username=<EMAIL_ADDRESS>

The request is made below to verify the registration. It is relevant to note that the application does not notify the user via a secondary email regarding the receipt or validation of this code.

POST /watch/users/register/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 83
Host: backend.application.tld

password=<PASSWORD>&device=2&vcode=<VERIFICATION_CODE>&username=<EMAIL_ADDRESS>

The anonymous registration process is equally weak. A username is generated using a random UUID code, and a predefined password (12345678) is assigned. To complete the registration, a previous login attempt is simulated with the generated UUID to confirm the non-existence of the account, which is done via the following path:

POST /watch/users/login/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/x-www-form-urlencoded
Host: backend.application.tld

password=<PASSWORD>&username=<RANDOM_UUID_CODE>

For anonymous registration, a verification code pre-fixed in the source code (112233), eliminating the requirement for a dynamic One-Time Password (OTP) mechanism.

POST /watch/users/register/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 83
Host: backend.application.tld

password=12345678&device=2&vcode=112233&username=<RANDOM_UUID_CODE>

The application automatically logs in next with a token received during the registration process, which is a 16-byte string encoded in Base64. In the following requests, the application authenticates using the HTTP header Access-Token with the value <SESSION_ACCESS_TOKEN>.

3. Insecure direct reference to objects in health data

Upon analyzing the application’s behavior in downloading and uploading user health data, an insecure direct object reference vulnerability (IDOR) was identified. The API uses a sequential numerical identifier (userId) to reference health data records. The critical point is that, in the upload and download routes, no session or authorization verification is performed on this field.

Knowing any sequential ID beforehand allows an attacker to obtain and modify the data of any user in the database. Since the ID is sequential, it is trivial to perform brute force on this parameter to access records of other users.

POST /watch/data/heart/v1 HTTP/1.1
content-type: application/json;charset:utf-8
Access-Token: <SESSION_ACCESS_TOKEN>
User-Agent: okhttp/4.10.0
Host: backend.application.tld

[{"deviceMac":"<DEVICE_MAC_ADDRESS>","deviceModel":"<DEVICE_MODEL>","heartTimes":70,"hour":15,"rtime":<UNIX_TIMESTAMP>,"userId":"<SEQUENTIAL_USER_ID>","zone":"+1"}]

4. Forgot Password Recovery

Finally, the password recovery mechanism was evaluated. The process involves: entering an email address, requesting the verification code, and entering the code and the new password.

A critical irregularity is observed in the handling of the verification code: although the server validates the code’s validity, there is no defense mechanism against brute force attacks.

POST /watch/users/password/v1 HTTP/1.1
User-Agent: okhttp/4.10.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 73
Host: backend.application.tld
Connection: Keep-Alive
Accept-Encoding: gzip

password=<NEW_PASSWORD>&code=<VERIFICATION_CODE>&username=<EMAIL_ADDRESS>

Given that the code is six digits, this provides a search space of one million combinations. This allows, with a target email address, the possibility of changing the user’s password without authorization in a maximum of one million attempts, without any security notification being issued to the affected user.

Conclusion

The detected vulnerabilities are not mere minor code defects, but systemic failures in the implementation of API security and identity management, which compromise the three pillars of information security: confidentiality, integrity, and availability, highlighting access to health data whose degree of protection must be maximum.