Studentkort-appen and client side security

16 sep 2013

Last year the Swedish student union card Studentkortet launched an app that were to be a compliment to the physical card that identifies you as a student (and thus gives you entries to the student clubs/events in Lund and get the discounts in stores and public transportation).

The idea behind the app is simple, just display a copy of the real card in the application, show that to the salespersons/bouncers along with an ID that has the same name, and you get in/the discount.

The alert reader will now ask herself WHAT? Just show an image on my android/iphone!?”.
No, don’t you worry, the security was not only based on displaying an image (that would be stupid). To make it difficult to copy the makers decided to implement a “flip” animation, where you can turn the card over with a flick in the app and see the back of the card. That will stop people from just print-screening the application!

So, can’t we just make a new app and copy the nice looking animation and be on our way? Definitely. But why bother rewriting everything? We had to take a look at the source code.

Since the app was deployed on Android you can just download the application and decompile it (check out this intro on android reverse engineering from last years CCC). As we suspected, the flip animation lay there ripe for the taking nicely decompiled.
So now, just take that class and implement your own application. Security broken! But would we really bother writing a complete new application? We had a look around the source.

It would be easier just to trick the application to render the card info we would like it to show. We checked out how they handled communication with the server (you have to log in to display your student union card).

public boolean verify(String paramAnonymousString, SSLSession paramAnonymousSSLSession)
    return true;

Oh. So They weren’t checking their certificates at all (but they had a SSL connection!).

Next step was to simply connect the phone to a VPN to my home network and stage a cute little Man in the Middle attack against the connection back to the server. What we did was simply to listen for certain calls which the application makes and replaced the image in the response. Hence this:

The reason I have waited to write about this until now is that I wanted to be nice to the brilliant people working with Student unions and nations in Lund (if your going there to study, join Blekingska for happy-fun-time).

After I reporter the MitM-issue it took a few month until it was fixed. Since the problem lay client-side I had to wait a long while for most people to update their software.

Ofcourse, they stil base their security on that the end-user will have a hard time copying software/images on their own devices…

blog comments powered by Disqus