Apps as Browsers: Can You Trust Your Mobile Apps?

During one of our brainstorming sessions looking for interesting research projects, our group thought about how most mobile applications are, in essence, “browsers-in-a-box”.

Let me explain. When you open your favorite app, chances are it tries to access certain web pages and display the results in a certain way. Not all mobile apps do this, just most of them. I’m not only talking about those Amazon or eBay apps (which obviously do behave like browsers that limit their queries to their specific servers) but also apps like Flipboard. I love Flipboard, but at the very core of it, it’s just accessing Facebook and Twitter and displaying it in a pretty way (okay, very pretty).

Can this make apps more vulnerable to something that regular browsers are expecting users to do i.e. behaving unexpectedly? For instance, if an app is performing canned requests to a single specific site, can someone take advantage of this behavior to subvert the app or the site?

I set out to work on this and created an environment to sniff all traffic coming to and from mobile applications both in Android and iPhone/iPad environments. I tested lots of apps, checking their traffic and looking for something that might be exploitable and I did find things.

There is one particular resource management game a friend recommended that apparently is very popular. It turns out this game rewards players with a prize every weekend. They don’t do that anymore and it might be my fault, although I never contacted them directly. The way this worked is as follows: if you liked the game’s manufacturer on Facebook, they would share with you a certain password that would unlock resources only during a particular weekend. They’d change the password every weekend and it would only work during those two days.

The way this was implemented was by means of a plain HTTP request ‘here is the password’ and response ‘here is 10 gold and 10 food for you, thank you’. In other words, you could alter the state of the game from the outside by means of a simple, unencrypted HTTP request. Spoofing the server to point to a local server in the lab setup and getting a fake response of ‘here is 10000 gold and 1000 food’ was, of course, trivial. If ever I’ll see my friend again and show him my progress, he’s going to be quite amazed.

The bottom line of this mini-attack was clear: unprotected canned HTTP is not trustworthy.

There were other problems in different applications, like a fitness application that sells exercise routines to be displayed in your Android device. The routines consist of exercise descriptions, images, trainer explanations with instructions, timings and order of each routine. All these materials are contained in an XML file with links to each image and sound file. Yes, you guessed it, the XML was downloaded in plain-text, unencrypted HTTP traffic. I could have tried to access the paid content by guessing the XML file names but I didn’t try.

I saw some others but my problem with the whole project came when I had to put my findings in writing. The problems I found were so heterogeneous that it was difficult to differentiate this project from any web application pentest. So the clients are mobile applications but I was really looking at somebody’s unsecure web code. At the end of the day, my starting axiom was too true: all mobile apps are essentially web clients therefore they are as unsecure as a browser and that’s how you should treat them.

A failed project, I hear you say? Perhaps, but it opened my eyes with respect to how we – and app developers – need to treat mobile applications as untrusted browsers-in-a-box.

Post from: TrendLabs | Malware Blog – by Trend Micro

Apps as Browsers: Can You Trust Your Mobile Apps?