I had almost forgotten about my experience with Worldpay’s Merchant Portal from just over a year ago, but my recent post regarding another payment processor helped to refresh my memory.
I occasionally help one of my family members’ small business with almost anything technology-related, including their e-commerce solution. In this case, I was helping them switch their payment gateway to Worldpay (advertised as “Secure Payment Processing”), which meant I had to become familiar with Worldpay’s APIs and Merchant Center web portal for setup and testing. Here’s a look at the main Merchant Center screen after logging in:
Obviously, the site looks antiquated and probably has not been updated much since originally developed — more on that in a bit.
One of the functions of the Merchant Center is to lookup orders and associated transaction details. Here’s a look at the screen used to view an individual order, showing some of the tasks that can be performed as well as a history of the respective credit card transactions at the bottom:
Note the links at the bottom allow the user to email the customer his receipt as well as view the transaction’s verbose details by clicking the “Approved” link:
As you can see, this screen provides some sensitive information relating to the customer’s credit card. Here’s a look at the request used to fetch this data:
GET https://merchants.worldpay.us/admin/transaction/transaction_detail.taf?TransHistoryKeyID=***REMOVED*** HTTP/1.1 Host: merchants.worldpay.us Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Referer: https://merchants.worldpay.us/admin/Transaction/OrderMgr.taf?_function=detail&OrderKeyID=***REMOVED*** Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Cookie: ***REMOVED***
Almost unsurprisingly, this request was vulnerable such that any authenticated user of the system could view the credit card transactions of any other merchant’s business, i.e. a simple IDOR. While the full credit card number is not displayed in this interface, the last four digits and the expiration date are — valuable information for an experienced attacker.
The issues didn’t end there. The Online Merchant Center also provides an interface by which the merchant can configure a WebPay form, essentially a preconfigured form used on merchant sites to accept credit cards (posting directly to Worldpay’s servers).
And the respective request made to fetch the existing form configuration:
POST https://merchants.worldpay.us/admin/merchantconfig/webpay.taf HTTP/1.1 Host: merchants.worldpay.us Connection: keep-alive Content-Length: 70 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Origin: https://merchants.worldpay.us User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36 Content-Type: application/x-www-form-urlencoded Referer: https://merchants.worldpay.us/admin/merchantconfig/webpay.taf Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 Cookie: ***REMOVED*** action=edit&mode=simple&webpaykeyid=***REMOVED***&webpayaction=ccsale&formname=
This request exposed a similar IDOR vulnerability (caused by manipulating the webpaykeyid in the payload), though the implications of it were arguably much more serious: an attacker could feasibly change the “Post-back” URL to one he controlled, meaning he would have received verbose details of payment transactions nearly immediately after they occurred.
Aside from this, having control of the payment form would allow other types of nefarious activity, e.g. altering the HTML (or perhaps even adding malicious JavaScript) on the target merchant’s site.
These are indeed quite serious issues for a global credit card payment processor, whose obligation to offer a secure platform for customers could not be more essential. How valuable might their Security Enhancement Offerings be?
Lastly, how is it possible in 2016 that such a company could still be running their merchant portal on IIS 6.0, which is not only over ten years old, but has been considered End of Life since July 2015?
HTTP/1.1 200 OK Connection: close Date: Wed, 06 Apr 2016 19:18:51 GMT Server: Microsoft-IIS/6.0 Content-Type: text/html
It is almost inconceivable that a company who is intimately familiar with PCI Compliance, and who inherently requires such compliance of most of their customers in order to use their products and services, is in such drastic violation of their own compliance requirements.
Further, reporting these issues to Worldpay was quite difficult since they also lack an official process. Though they ended up fixing the issues fairly quickly, getting in touch with the right contact took multiple attempts (initially through technical support), ultimately requiring me to email their entire executive team in order to speak with someone in information security.
Disclosure
2015-01-27: Initial report of vuln #1 to technical support contact, escalated to engineering
2015-01-29: I follow up, learn vuln #1 was patched
2015-04-09: I identify vuln #2, email entire executive team – discussed ongoing concerns with COO
2015-04-09: Discuss concerns w/ CISO and report vuln #2 details
2015-04-10: Vuln #2 confirmed patched
The larger question remains: how are these vulnerabilities being introduced (and not identified/patched) into a company’s software, whose entire business is working with some of the most sensitive user data in existence? Unfortunately, this is yet another example of the general failure of compliance, security seals, and auditing policies, resulting in critical software vulnerabilities that routine penetration testing should have identified.
Share this:
