In the name of Allah, the Most Gracious, the Most Merciful.
I. TL;DR
The simplicity in receiving payment from the online sales is certainly a dream for every seller. For actualizing this simplicity, Tokopedia has launched a feature which is “Tambah Rekening Bank” (Adding Bank Account) that could be used to receive the sales payment after every transaction processes to the buyer is conducted (in this case, after the buyer receive the item and confirm the reception of the related item). In the process, this feature itself could be used by the user to add more than one account that could be used as payment “receiver”.
Besides adding bank account to the personal account, the user is also allowed to delete the listed bank account that might not be used anymore in doing transaction. In the process, the bank account deletion itself is protected by a token (in general, it’s often related to the CSRF Token) so without knowing and using the user’s token, the deletion process wouldn’t happen.
However, the problem occurs when the token from every user could be used by other users. In other words, Tokopedia hasn’t implemented session limitation to the token that would be generated automatically from the system for its users. By utilizing this vulnerability, an Attacker could be able to delete all listed bank accounts that are registered by the users.
II. INTRODUCTION
2.1. Username VS Bank Account Name
There are two main different things in responding user enumeration context in this report. In general, user enumeration could be easily conducted in Tokopedia by only visiting https://www.tokopedia.com/people/X with X as a variable that could be changed with numbers. For example, the value of 11339854 is a value that indicates the account is owned by a user with username “yongki”. As we can see, every user or even seller could freely use any name to be their username, so “username enumeration” wouldn’t be a significant thing to be discussed.
However, this thing is different if we talk about the name of a bank account for the seller. Because this name would be quite important and couldn’t be hidden for the success of transferring process after the goods are sold.
To put it simply, username could be falsified but bank account name would be hard (not unable) to be falsified for the sellers that want to utilized the easiness in receiving payment.
2.2. Cross Site Request Forgery (CSRF) Token VS Tokopedia’s Token
Generally, CSRF is an attack that “forces” a user to do something that is basically “unwanted” in a web based application by utilizing the circumstance of the victim that is being authorized (login). In general, this kind of attack could be used because the absence of authentication process in doing a change or the absence of unique token that is allowed to process the related matter (the uniqueness of the token is usually given so the user wouldn’t be troubled by typing password to changes that are not quite significant).
In the Tokopedia site, any changes which are conducted by the user such as changing profile, adding bank account, adding address, or deleting the added list; is always followed by the token that is generated automatically by the system. The difference is, when adding a bank account or changing profile, the user firstly needs to input password or sending OTP.
III. SUMMARY OF ISSUE
As it has been delivered before, the security problem in this report is related to the vulnerability that “allows” an Attacker to be able to delete all listed bank accounts that have been registered by the users (especially sellers) in Tokopedia site. It’s important to be noted that the “benefit” in utilizing this vulnerability is the Attacker doesn’t need any interactions from the user because they only need to change the acc_id with their desired value (Aug 28, added) and also they only need to use their own token. In other context, the utilization of this vulnerability could also give information to the Attacker about the bank account owner’s name.
IV. INFORMATION AND SITUATION OF THIS POC
To be able to understand the existed problem, this section will be re-explaining the problem specifically about some information which is related to the general running process or even the root of the existed problem.
When a member tries to delete their listed bank account, then the member is indirectly sending two requests, which are a request for deleting and a request for confirming the deletion.
The sent request for the deletion process is as follows:
GET /ajax/people-4.pl?action=show_dialog_delete_bank_account&acc_id=XXXXXXX&v=YYYYYYYYYYYYY HTTP/1.1 Host: www.tokopedia.com Connection: close Cache-Control: max-age=0 Accept: text/html, */*; q=0.01 X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 DNT: 1 Referer: https://www.tokopedia.com/people/ZZZZZZZ/bank Accept-Encoding: gzip, deflate, sdch, br Accept-Language: en-US,en;q=0.8 Cookie: some of cookies value here
Table 1 Request for Deleting
Whereas the sent request for confirming the deletion process is as follows:
POST /ajax/people-4.pl HTTP/1.1 Host: www.tokopedia.com Connection: close Content-Length: 133 Accept: application/json, text/javascript, */*; q=0.01 Origin: https://www.tokopedia.com X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 DNT: 1 Referer: https://www.tokopedia.com/people/ZZZZZZZ/bank Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8 Cookie: some of cookies value here token=1ccf5fa39f76a4e7a8f4cb3be53ed6ba&acc_id=XXXXXXX&counter=&click_name=submit&action=event_dialog_delete_bank_account&use_master=1
Table 2 Request for Deleting Confirmation
After the user chooses option “Ya”, the listed bank account would automatically be deleted.
V. STEP TO REPRODUCE
5.1. Specify and make sure the account whose bank account wants to be deleted. In this context, Attacker (Yongki) wants to delete the listed bank account in Dicky’s account that is listed in acc_id “3631290”. This step could be conducted by sending request according to “table 1” section IV.
When the process is being conducted, then a respond would be send by the server in the form of bank account owner’s name and the token that is used in deleting the related bank account.
In the left picture, we could see that the Attacker (Yongki in this case) tries to access the bank account number of Dicky’s that is located in acc_id 3631290. When this request is sent, so the server will send a response to the user in form of “nama pemilik rekening” and the value of the “token” that can be used to deleted the referred bank account.
5.2. After that, the Attacker only needs to send a request which is displayed in “table 2” section IV by using the value of the token that is retrieved by the Attacker.
As we can see in figure 5, when the deletion of acc_id 3631290 with “Nama Korban” is conducted, the server sends a respond that shows as if the Attacker’s own bank account is the one which is deleted. However the fact is different, because the one that is deleted is the targeted victim’s bank account, which is the bank account of Dicky’s with bank account owner’s name “Nama Korban”.
The explanation of this situation could be seen clearer in the uploaded video (the link is included in this report (Section V).
* Figure 6 is retrieved from the previous video.
VI. ADDITIONAL INFORMATION
In order to maximize the given information in this report, here are the following conditions that are also needed to be paid attention to:
6.1. One token request could be used one time only. So, to delete another’s bank account, an Attacker needs to re-generate his token request to be used to the targeted account. From personal’s point of view, the problem is:
- 6.1.1. An Attacker could self-generate a token that could be used to delete listed bank account of other accounts’. In other words, there isn’t any section limitation when an Attacker tries to access the acc_id of other user’s;
- 6.1.2. Or the self-generated token by the Attacker could be used to delete the listed bank account anywhere. In other words, this token isn’t specifically made for its own self, but could be used for other parties.
6.2. In general, the request process for deleting is conducted by this flow:
However in the current condition, the existed flow could be manipulated in such ways as stated before, so the flow becomes like this::
6.3. Before deletion process, an Attacker could firstly see the “availability” of user’s bank account. This process could be conducted by sending request as displayed in “table 1” in section IV which also includes the value changing of acc_id (XXXXXXX);
6.4. PoC Video (Unlisted Public at Youtube): https://youtu.be/IS1yJxCRgbo
VII. RECOMMENDATION
In this case, to make sure that every token is only functioning for its own account (couldn’t be used by other users) would surely be a recommendation that can be implemented to cover the existed vulnerability.
Then, related to the User’s Bank Account Enumeration, Tokopedia could implement session control so every account couldn’t see other accounts’ sensitive information.
VIII. RESPONSE AND TIMELINE OF REPORTING
Tokopedia has responded and deployed the fixed very fast. Only a few hours after the report has been sent, the vulnerability successfully closed.
- Aug 18th, 2016 – Report v0.1 was sent via email;
- Aug 18th, 2016 – Tokopedia said they will check it internally;
- Aug 19th, 2016 – Report v0.2 was sent with simple mind mapping of attack;
- Aug 22th, 2016 – Ask the permission for bringing the topic to public;
- Aug 22th, 2016 – Tokopedia said they fixed the issue and will push the patch at that night;
- Aug 22th, 2016 – Acknowledge the Tokopedia’s response;
- Aug 23th, 2016 – Tokopedia said the fixed the issue and will send the award;
- (edited) Aug 25th, 2016 – Tokopedia Sent the bounty.
