Plimus vulnerability: transmitting unencrypted customer data
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.