CVE-2023-3064, CVE-2023-3065, and CVE-2023-3066

The reader should first take a look at the articles related to CVE-2023-3032 and CVE-2023-3033 that I published a few days ago to get more context.

CVE-2023-3064 - Information disclosure

This article discusses issues that used to affect the mobile application of Mobatime. The tested version resulting to this series of vulnerabilities is 1.3.20.

When launched for the first time, the application asks for credentials. If correct, the latter are stored locally and fields would be populated for the next times.

Intercepting the traffic between the server and the application (just firing up a BurpSuite and modifying the proxy settings of the phone) reveals that before authentication, a list of existing users is sent back by the server. One can notice here that an ID (154) is sent, because an authentication was performed earlier (but not in the same “session”), and the ID was saved and is advertised even if the password is not sent.

This first vulnerability was reported as CVE-2023-3064, and would ease further exploitation.

CVE-2023-3065 - Authentication bypass

While trying to authenticate to the server, the username and the passwords are respectively sent as param1 and param2 (see next figure). However, as demonstrated hereunder, no real authentication takes place. In the response sent by the server, some fields are populated, in case of successful authentication:

• return_s1: the name of the user (not exactly the same as the username);
• return_i1: really important, it is the identifier of the user;
• return_b1 and return_b2: two flags indicating that the authentication succeeded;

While receiving this response with populated fields, the application would assume that the authentication succeeded, and will store the identifier value in one of its variables. All subsequent requests would use this variable to authorise the user, by passing it as one of the attributes of the JSON payload. It is quite interesting to notice that the JSON response is quite generic. The returned values are put in return_sX, return_iX and return_bX depending on their type (string, integer or boolean respectively).

With the BurpSuite, it is therefore possible to intercept the response and to change it on the fly, in order to populate the fields that could make the application think that the authentication succeeded (the username as return_s1 is actually not relevant, as it is only used to display the correct name).

Some rules can be declared in BurpSuite in order to populate the appropriate fields in the response. To make it easier, all boolean values are set to true.

While receiving this response, the application would use the value 3 as our identifier, and fetch data based on this assumption.

CVE-2023-3066 - Broken Access Control (IDOR)

Another vulnerability affects the mobile application, being quite similar to CVE-2023-3033. Although the authentication can be bypassed and a user could connect as anyone else just by knowing their ID, there was another way to trick the application. Since the identifier is repeated in all subsequent requests, one can change the rule in BurpSuite and modify the identifier on the fly (e.g. turning all ‘154’ into ‘3’ to act as user n°3). It is different from CVE-2023-3065, because it could be also possible to authenticate in a regular way, and then act as someone else by faking the ID. Indeed, fixing CVE-2023-3065 would not necessarily be sufficient against CVE-2023-3066.

Conclusion

Chaining these three vulnerabilities possibly allows an unauthenticated attacker to gain access to administrative features, by first enumerating existing accounts, and authenticate as a privileged one. If you read the post about CVE-2023-3032, you may think thank it would be possible to gain RCE after bypassing authentication, but it was not possible on the version I tested. It is quite common among mobile application to meet such weak design where security strongly relies on the assumption that everything happens from within a kind of black box. Testing the security of mobile applications is sometimes not that different from a classical API intrusion test.

• 2024 2
• 2023 13
• 2020 12