While doing some research for Bankdroid during the hot summer days I decided to take a look at the increasingly popular payment app Swish. Swish, developed by HiQ for Sweden’s six major banks (Danske Bank, Handelsbanken, Länsförsäkringar Bank, Nordea, SEB and Swedbank/Sparbankerna), lets its users send and receive instant payments without the hassle of bank transfers.

Getting at the traffic

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’s¹ AndroidPinning 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 tweaking and tinkering I was finally able to see all the requests in clear text.

The API and mobilt BankID

At first glance nothing looked out of the ordinary. A simple XML API with a handful of endpoints and, as HiQ boasts on their website², using Mobilt BankID for authentication:

Betalningarna godkänns med hjälp av mobilt BankID, vilket gör att lösningen är lika säker som de olika bankernas internettjänster.

The way mobilt BankID was implemented was that a request that required authentication would return a BankID reference number and the app would, after the user had successfully signed with mobilt BankID, execute the same request again (this time including the reference number).
This seemed like straightforward and secure enough solution.

The phone number in the request

A thing that caught my attention was that the user’s MSISDN/phone number was included in the payment history request: …/mpc-swish/rest/paymenthistory/46701234567/ALL/0/30/.
Why would the server need the MSISDN if we were already authenticated?
What would happen if the MSISDN was changed to another user’s?

Authentication, but no authorization

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.

As the developers were completely unaware of this vulnerability it is quite safe to assume that is has existed since Swish was launched nearly 2 years ago (December 2012) and at the time of discovery affected over 1.4 million Swish users³.

Reporting it

Getting a hold of someone at Swish was another challenge. There’s no contact info on their website (only contact info for the connected banks) and their PR folks on Twitter weren’t very helpful.

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.

TLDR: Vulnerability in Swish let any user access any other user’s complete transaction history.

Update regarding use of GPL code in the Swish payments app

31 Oct 2014

There has been some discussion regarding the claim that Getswish AB is using GPL licensed code in their application. Getswish AB (via their press managers at The World Loves) are denying^4,5,6 that any GPL licensed code is used in the Swish payments app. Myself and others who have examined the app are confident that (a modified version of) AndroidPinning has been used.

Let’s take a look at the code from both projects. PinningTrustManager from AndroidPinning can be found at https://github.com/moxie0/AndroidPinning/blob/master/src/org/thoughtcrime/ssl/pinning/PinningTrustManager.java

The code from the Swish app was converted from dex format⁷ to java .class files with the help of dex2jar and the java code was reconstructed from the .class files using JD Project. The source for the reconstructed code can be found at https://gist.github.com/liato/1e8f11c017353109dd82

It’s important to note that reconstructing java code from a .class file doesn’t always produce the same code that was compiled but all method signatures and string literals are left untouched.

As you can see by comparing the two classes there are too many similarities for it to be an original piece of code.
For starters, both the class from AndroidPinning and the one from Swish is called PinningTrustManager.
Identical method signatures that are not inherited from the X509TrustManager interface⁸ include:

• private byte[] hexStringToByteArray(String)
• private TrustManager[] initializeSystemTrustManagers()
• private boolean isValidPin(X509Certificate)

Identical field declarations include:

• private final List<byte[]> pins
• private final SystemKeyStore systemKeyStore

They even have the same exact exception message for checkClientTrusted(X509Certificate[], String)!

throw new CertificateException("Client certificates not supported!");

The examined apk was downloaded 4th of July 2014 and can be found at http://nullbyte.eu/se.bankgirot.swish_2.0_6023.apk

Request to get the custom keyboard

GET /app/init-matrix-xml?height=600&width=628 HTTP/1.1
Cache-Control: no-transform
X-SHB-DEVICE-CLASS: app
User-Agent: Mozilla/5.0 (Linux; U; Android 4.0.2; sv-; Galaxy Nexus Build/ICL53F) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
X-SHB-DEVICE-MODEL: AND-4.0.2, 2.0.2, Galaxy Nexus
X-SHB-MCC: 240
X-SHB-MNC: 02
X-SHB-LC:
X-SHB-APP-VERSION: 2.0
X-SHB-DEVICE-ID: 123456789012345
Host: m2.handelsbanken.se
Connection: Keep-Alive

This is the first request that is sent to SHB when a user attempts to login. The height and width parameters define the desired size of the keyboard image returned in the response.

All headers starting with X-SHB are sent with every request and mostly contain information about the device that performs the request.

The keyboard matrix response

HTTP/1.1 200 OK
Date: Sat, 25 Feb 2012 20:56:29 GMT
Server: Apache
Cache-Control: private, proxy-revalidate
Content-Language: en-US
Connection: close
Content-Type: text/html;charset=UTF-8
Content-Length: 10517

<?xml version="1.0" encoding="utf-8"?>
    <response code="000" label="OK" >
        <matrix>
            <matrixId>009013526</matrixId>
            <matrixMetaData>0,5,7,11,13,14</matrixMetaData>
            <image type="png">
                <![CDATA[ ... base64 encoded png data, example below ... ]]>
            </image>
        </matrix>
    </response>

What we’re looking for in the response is the matrixId tag (we’ll need to send it back to the api when we’re logging in) and the image tag.

matrixMetaData tells the Android/iPhone app which buttons on the custom keyboard to make clickable. Not very interesting to us so we’ll disregard it.

Mapping a password to matrix positions

The image tag contains a base64 encoded transparent png image and looks something like this:

The image represents a 44 matrix where the numbers 0 to 9 have been placed randomly, the remaining 6 positions are empty.
When a user enters a password their real password isn’t sent to the api, instead the indices of the selected numbers (in a transposed 44 matrix) are sent as a concatenated string.
Let’s say the users password is 1234 and we’ve extracted the following matrix from the image:

Now the only thing that remains to do is to pick out the corresponding index for every number from the matrix below and send it to the api together with the username and matrixId.

The user enters the password 1234 and we get the positions 11,14,3,1.

Login request

GET /bb/glss/servlet/ssco_auth4?deviceid=123456789012345&username=8001010000&matrixPos=11,14,3,1&matrixId=009013526&entryId=privpnrpinse&appAction=doAuthentication&JSP_PATH=ssse&language=sv&country=SE&deviceClass=app HTTP/1.1
Cache-Control: no-transform
X-SHB-DEVICE-CLASS: app
User-Agent: Mozilla/5.0 (Linux; U; Android 4.0.2; sv-; Galaxy Nexus Build/ICL53F) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
X-SHB-DEVICE-MODEL: AND-4.0.2, 2.0.2, Galaxy Nexus
X-SHB-MCC: 240
X-SHB-MNC: 02
X-SHB-LC:
X-SHB-APP-VERSION: 2.0
X-SHB-DEVICE-ID: 123456789012345
Host: m2.handelsbanken.se
Connection: Keep-Alive

We’re almost there! But first a short description of some of the parameters:
deviceid - the device id from your Android/iPhone. Should be the same as the one in the header.
username - the users’ social security number in the format YYMMDDXXXX.
matrixPos - the positions of the numbers we calculated earlier.
matrixId - the same id that we got from our first request to the api.

Login response

HTTP/1.1 200 Document follows
Date: Sat, 25 Feb 2012 20:58:41 GMT
Server: Apache
Cache-Control: private, proxy-revalidate, no-cache="set-cookie, set-cookie2"
Accept-Ranges: bytes
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Language: en-US
Set-Cookie: JSESSIONID=0000Y4saPX4Aq_tCypur61bkzki:C4F1745366942536000007A8000098D000000000; Path=/
Content-Length: 226
Last-Modified: Sat, 25 Feb 2012 20:58:40 GMT
Connection: close
Content-Type: text/xml;charset=UTF-8

<response code="X8005" label="Kontrollera dina uppgifter. Efter tre felaktiga kodförsök spärras koden. I Internettjänsten kan du byta din kod om den har blivit spärrad. Alternativt kan du kontakta närmaste bankkontor."/>

Yea… well I don’t have a SHB account (yet) so I couldn’t get any further than this. I’ll update this post with more information about the API when I get my login credentials from SHB.