Vulnerability detected in PayPal request forgery protection system
An Egyptian engineer, Yaser Ali, during a PayPal study, discovered a vulnerability that allowed him to completely circumvent the CSRF attack protection system ( cross-site request forgery ). He described this vulnerability in detail in his blog , we translated and adapted the post describing the vulnerability.
For a successful attack of this kind, the attacker needs to make the victim fraudulently access a specially prepared link with which he can create requests on behalf of the victim. An attack is possible only if the user is authorized on the website that is being exposed to it.
The post has been prepared specifically for the corporate blog of the site about payment systems with monitoring of Web-payment.ru exchangers .
Reusable CSRF Tokens
The first thing Ali found was the ability to reuse the CSRF token, which allows you to verify the authenticity of each request made by the user. The token can be found in the body of any request, and its Auth parameter is changed for each individual request in order to ensure security. However, after a detailed study, it was found that Auth continues to operate for a specific name or email address of the user, even when reused. If an attacker manages to find any of the previously generated CSRF tokens, he will be able to easily perform actions on behalf of any user authorized at the moment.
Nevertheless, this possibility does not seem to pose a real danger, since it is impossible to get the Auth value from the victim's session.
CSRF Authorization Bypass
The Auth parameter is known to check every user request. Ali decided to check what would happen if an "unauthorized" attacker tries to send a request to send money. In this case, PayPal will ask the cracker to provide their email address or password. In response, the attacker can provide the email address of the victim, enter any password and thus intercept the request, which will contain a genuine reusable CSRF authorization token that allows authorization of this user's requests.
Further analysis showed that by intercepting a POST request from pages that can provide tokens before a user logs in, an attacker can get CSRF Auth, applicable to all users. Such a magical CSRF Auth can, for example, be found on the pagewww.paypal.com/eg/cgi-bin/webscr?cmd=_send-money . Having done all these actions, an attacker can fake almost any request on behalf of a real user. The application generates a genuine Auth token for the logged out user! After checking the process of changing the password on the service, Ali came to the conclusion that the cracker would not be able to change the user's password without knowing his secret questions. In addition, the user, in turn, cannot change his security questions without knowing his password.
Change security questions bypassing the security system
Further research showed that the process of "creating" secret questions, which starts as soon as the user starts registration, is not password protected and can be used to reset secret questions repeatedly, without entering a password. Thus, having CFSR Auth at its disposal, an attacker can fake this procedure and change the victim’s secret questions. The first attempt to "create" secret questions is not password protected and can be used repeatedly in the future. After performing all the steps described above, an attacker can carry out an attack aimed at specific PayPal users by faking requests using the CSRF principle and gain complete control over their accounts with it. Among other things, the cracker will be able to fake the following requests:
- Add / Remove / Confirm Email Addresses
- Change security questions
- Change shipping address or billing address
- Change payment methods
- Change user settings (notifications, mobile number settings)
- Add privileged users to a business account
- ... much more ...
Ali also wrote an interactive server in Python to automate the process and demonstrate how an attacker could exploit this vulnerability in practice.
Video from the author showing the hacking process:
However, the bugs themselves were discovered in early August, the engineer informed on time of the vulnerabilities that were closed, and information about them was released after that, so at the moment they no longer pose any threat to PayPal.
For his find, Ali, by his own admission, received the maximum reward that PayPal offers everyone who reports about any critical problems in protecting the system, $ 10,000.