January 14, 2014 · research websec ssrf

Accessing PayPal’s internal network - the critical nature of SSRF

Server Side Request Forgery (SSRF) is a relatively rare vulnerability, which allows for attackers to make requests on behalf of the server. Whilst SSRF has been heavily documented by ONSec as well as Riyaz Walikar, I was unable to find an example a real life example which demonstrated its critical and treacherous nature.

Here is a simple diagram which represents the attack flow for a web application vulnerable to SSRF:

img1

Case Study: merchants.billmelater.com

As a part of the PayPal bug bounty, I came across a critical SSRF vulnerability on merchants.billmelater.com. This vulnerability let me pivot through their internal networks, and could have potentially lead to information disclosure from their systems within the network.

The vulnerability itself was found within a test bed for BillMeLater’s SOAP API, which allowed for queries to be made to any given host URL. In order to understand this SOAP API, I have created a little diagram below:

img2

What’s so critical and treacherous about this?

I must note that this SSRF was very critical and treacherous in nature, mainly due to the way the internal PayPal networks were set up.

The SOAP API Test Bed on BillMeLater, referenced internal URLs such as http://business2:9080/pcgBatch/mitDebug.jsp
Through requesting this URL through the SOAP API Test Bed, I was able to pivot through internal hosts within the BillMeLater/PayPal network.
There was no authentication needed to view internal administration pages which allowed me to query their internal databases

These were some of the URLs/Paths I found in the HTML of internal web applications:

It would have been possible to request any one of these URLs, through the SOAP API Test Bed – effectively leading to a much bigger issue: the compromise of customer data.

Thanks for reading

Timeline of disclosure:

October 28th 2013 - Initial disclosure to PayPal about SSRF and ability to view internal administration tools

December 23rd 2013 - Acknowledgement of report

January 10th 2014 - Initial Payment

March 18th 2014 - No reply to my further security reports on fixing the SSRF further - no acknowledgements of further security reports

March 18th 2014 - Public disclosure on blog