I. ABSTRACT

As could be seen previously at another report, for completing the support to all of PayPal’s merchant, PayPal provides the technical support portal (located at: https:/www.paypal-techsupport.com) for their merchant to communicate each other when they would like to discuss about the integration, feedback about the needed new feature, or any technical issue that could be face by PayPal’s merchant.

Figure 1 PayPal Technical Support Portal

Just like a common support portal, for facilitating their customer to track the issue, PayPal providing the feature that could be used by their customer to registering themselves with their own account. With the ability to create their own account with their own credential (password), generally users will meet one of the famous common feature such as “Change Password” feature.

Figure 2 Change Password Feature

But the problem exists when the “Change Password” feature didn’t works well to protecting the customer from unauthorized changes. In this case, the Attacker could bypass the “Current Password” Protection feature at application to change the victim’s password. In other words, without supply the current password / the knowledge of current password, the Attacker could change the victim’s password.

II. INTRODUCTION

Not much thing that could be explain at this part since this we are very sure if the readers are really familiar with the “change password feature” that protected by “current password” field. By this consideration, then we could go directly about the flow that provides by PayPal to use this feature.

As we could see from those full decoded parameter, there is a common interesting part at the “Form” parameter. There is “currentValue” parameter that act as the parameter to receive the input of previous password that type by user to change their password. In those decoded value, it tells us if the current password is “Password!#%” and the new password is “Password!#%!#%”.

The problem in this situation is: if we remove the “currentValue” parameter and leave it only “Contact.NewPassword”, then the application still processing the request and change the user’s password without the needs to validating the current password.

III. PROOF OF CONCEPT

As stated earlier, we should remove the “currentPassword” parameter completely to executing this PoC. Please note, the “complete” word in here means the %2C%22currentValue%22%3A%22%22 parameter (which is: ,”currentValue”:”” )

Here are the step by step to reproducing the issue:

3.1. The first one is put a random password at the “Current Password” Field. For example, asdasdasdasdasdasdas.

Figure 4 Submitting Random Old Password

3.2. The second one is put the new password at the rest of the field just like the picture above;

3.3. Setting up the Burpsuite interceptor and make it “on” so the request could be intercept later;

3.4. Back to the browser and send the request by click the “submit” button or press the “enter” key;

3.5. After the request has been sent, then go to the interceptor again and see the request.

Figure 5 Hold the Request with Interceptor

As we could see, there is a “currentValue” parameter with the asdasdasdasdasdasdas value. It could be seen with: %2C%22currentValue%22%3A%22asdasdasdasdasdasdas%22

So, all the things that we should conduct is remove completely those parameter from %2C%22currentValue (which is ,”currentValue) until asdas%22 (which is asdas”).

IV. PROOF OF CONCEPT VIDEO

As a support of explanation, here are some information that could be helpful to looking the video:

4.1. The account of the victim is circle.idts2@hotmail.com

4.2. The current password is Sup3rN3wPassw0rd!#

4.3. Attacker put a random password, which is asdasdasdasdasdasdas;

4.4. Attacker tries to change the password into the new one, which is N3wPassw0rd!#!#!#

4.5. Attacker send the request and intercepting it with interceptor;

4.6. Attacker remove the asdasdasdasdasdasdas value from the request;

4.7. Attacker remove the %2C%22currentValue%22%3A%22%22 parameter from the request;

4.8. Attacker send the request to server;

4.9. Application shows an error;

4.10. Attacker refresh the application and get logout automatically;

4.11. Attacker tries to login with the new password that made by the Attacker itself;

4.12. Attacker success to login.

V. LESSON LEARNED

One of the very useful lesson to be learned is we should try to spare our time to read any research that conduct by another researcher. As an information, trick was inspired by the both of research that conduct by Henry Hoggard (PayPal 2FA Bypass) and Suleman Malik (Password Validation bypass at Blackberry).

VI. ADDITIONAL NOTE

The initial bounty was sent on August 10th, 2017. And the final bounty was sent on October 27th, 2017.