Security Flaw in ‘Swish’ Reveals Transaction History of Users

Security Flaw in ‘Swish’ reveals transaction history of other users.

‘Swish’ been designed by Six major Swedish banks as a cost-effective alternative for credit card processing machines and is used by attaching a card reading device to a mobile phone. The banks also released a free Swish Payments mobile banking app which is available for both Android and iOS devices and acts as a perfect solution for cardless payments throughout Europe.

SEB, Handelsbanken, Nordea, Danske Bank, Länsförsäkringar Bank, alongwith Swedbank and Sparbank partnered with HIQ for this one stop solution for realtime payments without the user needing a payment card or a visit to the bank.  It permits Swish users to transfer money in real time, identifying the recipient not by the number of their bank account, but by their mobile phone number.  As per statistics provided by Swish, at the beginning of October 2014 there were more than 1.7 million active Swish users in Sweden.

So far so good

Everything about Swish looks perfect and is supposed to be a great way forward in banking, both for users and the banks but for one problem.  A flaw in Swish allows users of the service to view details of the entire banking transaction history done by others simply by modifying the payment history request.

This was noticed by a security researcher from Nullbyte.  The researcher, whose name has not been given on the Nullbyte blog studied the Swish from security point of view given its immense popularity and ease of use.  The researcher states,

My first thought was to set up a transparent proxy to be able to observe the traffic between the app and the Swish backend, but that didn’t go as smooth as I had hoped. It turned out that they were using a self-signed certificate and had therefore implemented certificate pinning (Moxie Marlinspike’s1 AndroidPinning (available on Github) to be precise, licensed under the GPLv3 – meaning that Getswish AB is obligated to hand over a copy of the Android app’s source code to anyone who requests it) in their apps. Whether planned or not this solution made the app more secure by mitigating man-in-the-middle attacks – it also meant that I had a new obstacle to overcome as I wouldn’t be able to simply connect through my proxy. After a bit of twerking tweaking and tinkering I was finally able to see all the requests in clear text.

Proof of Concept (PoC)

According the Nullbyte researcher, This is done through Mobile BankID, a widely used infrastructure for electronic identification for mobile devices in Sweden. The implementation of Mobile BankID in Swish consisted of an authentication request that would return a reference number. The same request would be executed again, after the user authentication, containing the reference number.

However, the researcher noticed that the link with a payment history request would include the MSISDN value, which is the phone number of the user.  The researcher found out that such requests use Mobile BankID service only for authentication, not for authorization, allowing access to the payment history of any user of the service just by changing the MSISDN value.

Apparently, in the case of payment history requests, mobilt BankID was only used for authentication and not for authorization. An authenticated user could retrieve any other users complete transaction history simply by changing the MSISDN in the request. The Swish server never checked whether the user was authorized to make that request or not. The transaction history includes phone numbers, full names, datetimes, amounts and messages for every person you’ve ever sent/received a Swish payment to/from.

The researcher alleges that the flaw may have existed since the launch of Swish, which happened in December 2012 and could have affected n number of users since then.  However HIQ has taken cognizance of his research and the flaw has been eliminated as of now.

After emailing all of the affected banks and describing the problem a couple of them actually replied and a day later I was contacted by someone in charge of the project. A short week later the vulnerability was fixed and everyone was happy again.