How to conduct electronic wallet APP vulnerability analysis

Razer Pay is widely used in Singapore and Malaysia. In this Writeup, the author used APP reverse analysis and Frida debugging to discover the user signature in the Razer Pay Ewallet. (Signature) generates a vulnerability, which can read the chat history of Razer payment users, delete the user's bound bank account, and steal the user's personal sensitive information. The vulnerability eventually earned Razer an official reward of nearly $6,000. The following is the author's idea of ​​vulnerability discovery, which can only be used as a reference for posture learning.

Vulnerability Background

Razer Inc (RΛZΞR) is a gaming peripheral equipment company founded in Singapore. It is also known as the "Green Light Factory" and has begun to enter the market in recent years. Consumer electronics business. Razer's two headquarters are located in Singapore and San Diego, USA. Listed on the Hong Kong Stock Exchange in November 2017, its products are targeted at gamers, and most of its products are named after carnivorous animals. Electronic wallet Razer Pay was launched in 2018. In May 2020, production of surgical masks began.

In the request tamper-proof mechanism of Razer Pay Ewallet, in addition to auth_token, the parameter signature is also used to perform signature verification on requests from different users. Each of the services Both GET and POST requests will be accompanied by an encoded signature parameter value and user id, as shown in the following figure:

Therefore, any attempt to tamper with any request parameter and resend it will result in Invalid, but APK reverse analysis found that Razer Pay Ewallet has a user signature (Signature) generation vulnerability. Combined with Frida's analysis and utilization, it can automatically calculate and generate a new user signature (Signature), which can lead to many The problem of ultra vires (IDOR).

When I used Burp to capture the network request of the Razer Payment APP, I found that due to the protection of the user signature (Signature) in the request, many of the parameters cannot be tampered with. Therefore, I first I thought of registering another Razer payment user for testing, but in the scenario where two users made the same request, after the session Payload was replaced, the execution was invalid. The reason was that the session had a user signature (Signature). Ask for protection.

I decided to analyze the generation mechanism of user signature (Signature). With the help of decompilation of apktool and Jadx-Gui, I gained a code-level understanding of the operation of the APP, and found that there is a name in it. It is the method function of "MD5Encode". As you can see from the name, it uses the MD5 encryption algorithm. After combining some parameter payloads, I decided to try to generate a user signature (Signature), but no matter how hard I tried, I could not generate a correct user signature. I guessed that the order of parameters might be wrong, or it was an unconventional MD5 encryption.

Delete other users’ bound bank accounts

Don’t abandon or give up, I copied all the relevant codes involved in user signature generation, and then used The IDE debugging tool IntelliJ IDEA was used to try to generate it. Finally, in the application of the "MD5Encode" method, I combined the correct parameter order. However, due to code confusion, some fine-tuning was needed, but it was not too difficult. Finally, insert the correct parameter values ​​into the previously generated request body, and use the above code to generate the correct user signature (Signature) string!

(The editor analyzed that in the following generation process of multiple user signatures, the user's own token is used as one of the parameters, and then through the MD5Encode method, different user IDs corresponding to multiple users can be generated. User signature, that is, each user signature Signature assigned to multiple users by the Razer server can be successfully generated)

Thus, The first thing I thought of was to test the unauthorized access vulnerability (IDOR). I chose a relatively sensitive API interface/deleteBankAccount, which is the operation of deleting the bank account bound to the user. Then in the test scenario of two accounts, it was successfully deleted. The linked bank account of another Razer Pay user!

Join chat groups created by other users

At this point, I think there must be other API interfaces protected by Signature that have IDOR override issues. So I tried to do a wave of tests using the above method, but found nothing. Moreover, other API interfaces used different code obfuscation methods, which caused me to spend a lot of time researching and analyzing them. When you have no clue, try using Frida. Frida is a very easy-to-use debugging tool. I can use it to identify some method functions that can be hooked. Combined with the above MD5Encode method, I can find the correct electronic wallet. Code package, you can also use these methods and functions to generate a new correct user signature Signature.

The function implemented by the following frida.js code is to generate a new user signature for the current user to join the chat group created by other users:

<br>

<code><code>// frida. js - Use this for recalculating signature for adding user to other people's chatgroup

<code>##console.log("Starting...")<code>

<code>Java.perform(function () {<code>

##var MD5 = Java.use('com.mol.molwallet .view.MD5')<code><code>

##MD5.MD5Encode.implementation = function (arg)

<code><code>

{

<code><code>##console.log("Hooking class MD5 - method MD5Encode")

<code><code>//Extra step - calculate new signature

<code><code>##var ret_value = this.MD5Encode("groupId=1x9&userIds=95xxx7&token=b6fxxxd3-2xxc-4xxf-bxx7- 7fxxxxa6")

<code><code>##console.log("[ ] signature= " ret_value)

<code># #//Call method with original arguments so app doesn't crash ..<code>

##var ret_value = this.MD5Encode(arg) //original value<code> <code>

console.log("original ARG: " arg) <code><code>

##return ret_value;

<code><code>

}

<code><code>

})

<code><code>But Running Frida requires root-level access. Fortunately, I discovered a server-side vulnerability that allows an attacker to perform operations on a rooted mobile device. The following is the command to start the Frida service on a mobile device:

<br>

$ adb shell<code><code># sudo su

# /data/local/tmp/frida-server<code>

After that, in another terminal window, run the following command:

$ frida -l frida.js -U com.mol.molwallet

<code>Then, in the mobile device, I open the Razer Payment APP, any call to the hook method "MD5Encode "The above operations will execute the above frida.js script. Finally, I can generate a valid and correct user signature Signature for a specific user request. The test case here is that I can generate a user signature for myself and use it as Verify your credentials to join a chat group created by other users. The danger of this method is that you can join a group unknowingly and then obtain other people's chat content, or click to claim and steal the information sent by others. Red envelope.

<code>

Other security issues caused by

Using the above method, I removed all other API interfaces affected by Signature After testing, I found that the amount of red envelopes shared by users in group chats can be obtained from these API interfaces. In addition, the transfer records and personal information of other users can be modified and viewed.

The above is the detailed content of How to conduct electronic wallet APP vulnerability analysis. For more information, please follow other related articles on the PHP Chinese website!