It is Ibrahim M. El-Sayed, a security researcher at vulnerability-lab. Today I am going to explain to you our journey of finding vulnerabilities in PayPal. Our agenda for this article will include: why PayPal acknowledged us in the wall of fame, our methodology for finding vulnerabilities, an example of our vulnerabilities, our reporting technique and I will finish with some tips.

We, vulnerability-lab, got acknowledged by PayPal for finding more than 70 vulnerabilities in PayPal services. We found different types, such as Blind and non-Blind SQL Injections, server and client side cross-site scripting vulnerabilities, Mail Encoding Web Vulnerabilities, Auth Bypass Vulnerabilities, and more.

We were actually in the top ten security researchers of the wall of fame. After explaining our contribution toPayPal, in this section, I will explain our methodology of hunting vulnerabilities. We usually work on teams and we divide the work up by the different services. For example, I work on a service that is hosted on a subdomain called test.paypal.com. We always do our testing manually.

We use Firefox as our browser for hacking. We use some add-ons to help us in gathering information about the server and ease the manual testing.Some of the tools are Tamper data, Burp suite, live HTTP headers, cookies manager+, hack-bar and firebug.

We usually try to understand the logic behind the services and we mark every place where the service accepts an input from the user directly or indirectly. By directly, I mean data like company name or address. Indirectly, for example, when you upload an image, the Meta data inside an image might get processed and that could be vulnerable. After logging all possible spots, we try to estimate what vulnerabilities might be there. We estimate that we might find a SQLi persistent there etc… After collecting the data and hypothesizing, we start injecting some malicious code until we discover some vulnerability. Sometimes, we face some difficulties when exploiting the vulnerability. At that stage, we group as a team and think of how we can exploit or bypass such a restriction.

In this section I will explain one of our vulnerabilities at PayPal. This vulnerability has already been patched. Its title on our website is: “Paypal Bug Bounty #48 –
Persistent Web Vulnerability”. It is mainly a persistent XSS vulnerability. It is located on a service called GP+. GP+ objectively analyzes and assesses the quality and findablility of online stores. We analyzed the scanning process of the GP+. It was vulnerable in many places, but the one I liked the most was the following. In one stage of the analysis, the PayPal service reads the robot.txt on the target website. It saves its content and when the user checks the analysis results, it displays the robot.txt content.

The idea occurred to me, what would happen if we have a robot.txt file that contains malicious code. What would be the behavior of the PayPal service when it saves the content and displays it? Is there any kind of filtering in the input or the output? Luckily, PayPal doesn’t use any kind of security checks for the input coming from the robot.txt file and it displays it as it is. In the following picture you will notice the code getting executed perfectly from the malicious robot.txt file

We usually have a standard reporting technique. We write our report that includes all the details for the vulnerability. For example, it includes the URL, Proof of Concept, proposed solution for the vulnerability, the risk of the vulnerability and more. We also attach screen shots for the vulnerability we found, and finally we attach the vulnerable pages after being exploited.
To clarify, if the vulnerable page is search.php, we download the page with the payload inside and we attach it with our report. We send the report to the
PayPal security team at [email protected], which you can use to report any vulnerability you find. PayPal sets you up with an account on https://keys. ebay.com and you start communicating with them through that account.

Finally, I would like to mention some tips that would help you in hunting for vulnerabilities. The first thing I would like to advise you is to work based on a good methodology that you set it up in your mind. You should understand the logic of the service before you test. This will ease the problem and don’t work like a tool that tests blindly all inputs. You will find many times that the logic itself is vulnerable. I also recommend you work in teams in which you encourage each other and share knowledge.

I don’t need to mention that you should NEVER lose hope; you should keep trying and trying until you discover something and always believe in your potential. Last but not least, if you have any questions regarding the article, the vulnerability or anything else and you think I can help, you would be more than welcome to contact me on: storm@ vulnerability-lab.com

About The Author

Ibrahim Mosaad, Security Researcher at Vulnerability Lab