Plimus vulnerability: transmitting unencrypted customer data

Floor Terra - 2011-06-03 12:41:00
Plimus Inc. is a company that handles online payments for websites. The websites don't have to deal with all kinds of credit card companies and banks. Just create a account at Plimus and let them handle all your payments. This means Plimus has access to sensitive customer information and they should take extremely good care to protect this information. However, I will try to explain how a few mistakes from Plimus may harm the security of your webshop and the security of your customers.

To explain the problem, I first have to explain what Plimus is calling an IPN. IPN stands for Instant Payment Notification. When a person wants to buy something from your site, you send them to a special page on the Plimus server. This page lets them create a Plimus account or login with their Plimus account. This will tell Plimus all kinds of information about the customer that is needed for the payment and shipping of the product. The next step is for the customer to actually pay for the product and confirm some last details. When the payment is complete, the customer is redirected back to the original webshop. However, the webshop doesn't know if the payment succeeded, where they should ship the product, etc.. This is where the IPN comes in.

The webshop has specified in advance a special url (like http://www.example.com/plimus/ipn.php) where Plimus should send an IPN. After a customer completes a payment, one of the Plimus servers sends some data to this url through a HTTP POST request. The webshop should handle all this information and, for example, put the customer's name and address in their shipping database so they can ship the customer their favorite package.

An observant reader might have already spotted the problem, but don't worry if you didn't. These POST requests contain lots of data about the customer, like name and address (full list here). All this data is send unencrypted over the internet. Anybody listening to the traffic could not only read all the customer data, but also change the contents of the IPN.

The most simple defence against eavesdropping the IPN is to use HTTPS. HTTPS has several nice features that can be used to identify the host you are talking with, prevent eavesdroppers to listen in on your traffic and prevent the same eavesdroppers to insert or alter traffic. However, Plimus doesn't use most of these features.

The following points are not checked by Plimus:

  • Sudden changes in the certificate
  • who signed the certificate (you can use self signed)
  • If ssl is used at all

These are all things Plimus could easily check for. A sudden change in certificate is almost always bad news. And if it is legitimate your admin would know about it. So generate a big fat warning and alert the webshop.

And accepting a self signed certificate should generate some alarms too. What respectable webshop uses self signed certificates? Any web-browser would prevent users from visiting webpages with self signed certificates by default. Why would it be secure enough for sensitive customer information?

And finaly, Plimus should just stop sending IPN's over plain http. period.


There is more than I can fit in one blogpost. I still have problems with their handling of Parameter "protection", sharing of user credentials, whitelisting of ip's instead of proper authentication. Expect updates soon.

And to Plimus: I am still willing to talk to you. You have my email address and phone number.