Blue Code mobile payment – All show and no substance [3. Update]

March 20, 2016

[Update]
The vendor contacted me and told me they are working on a fix right now, which should be released shortly. I also got contacted by 3rd parties and they asked if the whole system is broken or not. To make it clear for the non experts. My findings are “easily” fixable and I can’t say anything about the whole system as I didn’t look at it. The vendor has fixed following 2 problems

bad HTTPS setup for the webservice
client certificates length (now RSA2048).

[/Update]

Shopping in my local super market I saw an other customer paying with a barcode on the display of his mobile. Looking a little bit around I saw also the ad for it. The service/product is called Blue Code and is from a local company Secure Payment Technologies GmbH based in Innsbruck and is used by some big retail stores.

As you know me, I like to know how stuff around me works and how secure they are. Searching around a little bit in the Internet I didn’t find anything above marketing stuff on how the system works. This intrigued me, as not documented normally means there are some skeletons in the closet. So this post is about the my look into the system.

I normally start with the basics. In this case checking the HTTPS stuff and taking a look at the Android App. Both are done without installing the App on one of my devices.

First Look

Looks good, but I saw something additional:

Yes, that’s a wild card certificate. So even if they have an other more secure TLS setup for the payment stuff this certificate would be valid for it. That’s bad security practise. But maybe they use an other domain for the payment stuff or do certificate pinning. So I downloaded the APK. Use this nice site to download the Blue Code APK on your desktop for analysing. APK files are just ZIP files with a special structure, so I’ve extracted the files and took a look at the strings. I took a look at the last 3 versions which I could download.

I found something interesting in the Blue Code_v1.2.0_apkpure.com.apk (the oldest of the three) …

$ strings classes.dex | grep http [Copyright (c) 2000-2014 The Legion of the Bouncy Castle Inc. (http://www.bouncycastle.org) ... #http://202.4.114.227:8080/merchants ... https://sdk.hockeyapp.net/ https://support.bluecode.com/a/

The Bouncy Castle is a crypto library for Java in this case and HockeyApp is for a platform for application development. The IP address is more interesting, it belongs to an ISP from Bangladesh. Hey? The company is from Tirol / Austria – outsourced development? The Blue Code_v1.3.1_apkpure.com.apk and Blue Code_v1.3.2_apkpure.com.apk does not contain that string. Also the crypto lib seems to be changed. Anyway the host was not reachable from my computer so I think that’s legacy host that got removed.

So far it seems no other domains are in the App. A search for sub domains shows following:

$ strings resources.arsc | grep bluecode.com ... https://www.bluecode.com/login mobile-ca.bluecode.com mobile-api.bluecode.com ...

Oh, that TLS setup looks not that good:

hm .. lets take a look at the certificate …. oh … its the same:

So different servers use the same wild card cert … that’s really “good” security practise :-). Are TLS certs too expensive? https://mobile-api.bluecode.com uses also the same certificate and the same TLS setup as https://mobile-ca.bluecode.com (run on the same IP address).

Both hosts look like web services … so I guess the App talks with them, which means the website has a better security than the payment web services? I should look deeper into it.

Note the vendor: Certificate pinning helps only if you don’t use the same wild card certificate for all services, this way if you’re web server gets compromised an attacker can use that for fake your payment webservices.

The setup for a deeper look

Now it is time to look at the traffic the App generates while talking to its servers. Looking at the files packed into the apk file I saw that under /res/raw/ multiple CA certificates (including the CA for the web site and service certificate) got shipped. So I’ll guess there is some certificates pinning done.

So I got my old Nexus 7 out from a storage drawer, and did following to it:

Unlock Bootloader
Factory restore with Android 5.1.1
Rooted it
Installed Xposed Framework
Installed JustTrustMe and SSLUnpinnig Modules for Xposed

After that I installed Burp and configured it as an HTTPS proxy on my PC. I’ve already shown how to do that in this blog post. After that I needed only to do following on the tablet:

configure Burp as the proxy for the Wifi connection
install the the Burp CA on the tablet
download and install the BlueCode App.

First launch of the App

At first launch you need to provide a PIN code for something – it was not for what I first thought, but more about that later. After entering you PIN twice the App starts talking with the server.

The two requests to

https://www.bluecode.com/json/support_mobile_app_pages.json and
https://www.bluecode.com/json/support_mobile_allgemein.json

return only some text for the App. But the next request is more interesting, it is a certificate signing request (CSR):

And there is also a parameter “pin” in the request (salted hash?). Looking at the CSR it seems to be a little short. Anyway the response from the server is a certificate.

Taking a look at that certificate shows following:

I know now why it looked that short, its a 1024 RSA certificate, but signed with SHA256. Someone didn’t understand crypto here. Signing an RSA1024 Key with SHA256, does not make any sense. If you won’t believe me take a look what NIST(National Institute of Standards and Technology) says. From the PDF:

RSA 1024 has a security of lower than 80bit and should not be used for years now!!!

After this request, the next request gets send to mobile-api, with the authToken the App got from the previous request.

This request fails with the HTTPS proxy as the App makes a TLS client authentication, for which my proxy does not have the private key. After some short searching I found it under: /data/data/com.spt.bluecode/app_Certificates/client_certificate_keystore

I copied the file to my computer and tried to open it … I “just” need to get the private key now.

Lets stop with looking into the security of Blue Code for mow, as the weekend is almost over and the weather was really good and I needed to go ski montaineering also. But maybe I’ll look later deeper into the system …. So far I found following security problems:

bad HTTPS setup for the webservice
wildcard certificates used over multiple servers/services
client certificates length (RSA 1024bit) which should not be used for years

So many security problems after looking at it only for some hours does not bode well ….

[Update]

It seems the software has a check that should detect if a devices is rooted …. does not seem to work in my case, maybe I don’t have that directories on my system … 😉

[\Update]

ps: Has someone of you documentation on the protocol of Blue Code? This would allow a high level check and theoretical security check without looking at the traffic.

In Austria, IT Security | No Comments

No Comments yet »

RSS feed for comments on this post. TrackBack URI

Blue Code mobile payment – All show and no substance [3. Update]

No Comments yet »

Leave a comment