Find crazy stuff in mobile app communications (and get free stuff!)

Here’s a pop quiz for you: how much data do you reckon this iPad app downloads when it first runs? I don’t mean how big it is to download from the App Store (it’s 25MB), I mean after you download it then simply tap the icon to fire it up, how much data does it pull down if you don’t touch it again? Take a close look and consider the answer before reading on:

Now you’ve probably done what I would have done – looked what you can see on the screen, speculated about how you’d build it in a way to make it respond quickly to someone flicking through the app (it’s a performance car magazine you can buy subscriptions to) and concluded – what do you reckon, maybe a few meg? Seem fair?

Try 1.8 gigabytes. You heard me, that’s not a typo. You open up this 25MB app and it’ll pull down dozens of files of dozens of meg each when you run it. Won’t someone please think of the bandwidth!!!

But this is the thing with mobile apps – you’ve got absolutely no idea what they’re doing in the background when it comes to how they chat over the net. It’s not just nutty approaches to chewing through your bandwidth though, you oughta see what goes on security wise…

Here’s a good example I wrote about a few years ago. Imagine you’ve done a hard day’s shopping, you emerge tired and poor, looking for your car and… you can’t find it. No dramas, you just whip out the phone running the centre’s “Find My Car” app, punch in the number plate and it automagically identifies your vehicle because sensors OCR’d the plate when you parked. You can then choose which car is yours after which it will give you directions to your car:

Because privacy is important, the results are limited to four and the plates are all pretty much illegible but you can still make out from the pics above which car is yours, especially given you’re being shown the vehicles that are the closest match to the plate you entered (OCR ain’t a perfect science). Any stalkers / jealous husbands / NSAs would have to manually enter every possible plate and build up a database of comings and goings four at a time and even then not know exactly what the plate is. Except that they wouldn’t because it was way easier than that.

For reasons that later emerged to be convenience more than anything else, the API that is called when you search for a plate returns everything. Obviously some sort of parking bay ID and a link to the photo, but also the raw plate itself, the entry time and to top it all off, the limit of four results was just a query string parameter. Oh – and no brute force protections so you can call the API as many times as you like and ask for as many cars as you like and know exactly who has come and gone when. Whoops.

When APIs are stood up behind rich client apps, crazy things happen. These are but two examples and I have many, many more both on this blog and not suitable for public sharing (ask me about banks over a few beers one day). What many developers don’t understand is that how mobile apps communicate to APIs over the web is really, really easy to identify. And manipulate. And exploit. This is exactly the sort of stuff I walk you through in my latest Pluralsight course, Hack Your API First. This course got off to a fantastic start shooting up to number 11 on the charts of well over 3,000 courses; clearly this topic resonates, so much so that I want to make it more accessible to more people.

Here’s what I’m doing: I’ve recorded a walkthrough of how you can easily discover what’s going on with your apps. You find crazy stuff like I’ve found here and leave a comment explaining it and you get a free Pluralsight pass so you can go and learn how to find even more crazy stuff. Of particular importance for those of you in the software building business, this means actually learning how to build more secure APIs. Here’s how to go about it:

Step 1. Learn how to discover app communication with APIs

I’ve made this dead easy and recorded a 20 minute video that walks through how to configure your PC with Fiddler, set your mobile device to use it as a proxy and then shows what sort of crazy stuff you can find, including details of the EVO mag example above. Watch it here:

Make sense? If you’re not sure on how to install Fiddler’s root cert on your device, check out the docs here.

Step 2. Go forth and explore

Now the fun bit – finding out what’s been going on behind the thin veneer of your apps. I tend to go through apps that talk over the web one by one and look for some pretty common patterns. On the security front, the biggies I see tend to be one or more of the following:

1. Logging in over HTTP and not HTTPS (credentials sent insecurely)
2. Not validating the SSL certificate when HTTPS is used (remove Fiddler’s root cert from your device – if stuff still loads, validation almost certainly isn’t happening)
3. Returning sensitive data you shouldn’t be seeing (the “find my car” example earlier is a classic)
4. Sending data pre-auth you should only have access to post-auth (see the British Airways example in the video)

Other crazy stuff you’ll find in your apps includes:

1. Really wasteful bandwidth practices (EVO was a classic, but there are heaps more)
2. Nasty tracking by device ID (it’s not meant to happen any more, see the examples in my post on Secret iOS business)
3. Invasive practices you wouldn’t reasonably expect from the apps (sending contact info, sharing geolocation, etc.)
4. Heaps of other stuff – use your imagination!

By no means are either the risks or crazy practices in mobile limited to these, the course goes through things in much more breadth and depth and it won’t take too much poking around using the practices I show in the video to find a heap of other issues yourself.

Step 3. Share and get a free Pluralsight pass!

I’ve got a whole stash of these guys to give away:

This gets you into the full library of 3,000+ Pluralsight courses including, of course, my courses which get you right down deep into the sort of risks you can find in so many of your apps and how to properly secure them when you’re building APIs yourself.

Just a few guidelines to keep everything in check:

1. When you find something crazy, leave it in the comments below rather than emailing it or tweeting it (I’ll reply here if you’re up for a free pass)
2. Make sure you explain why it’s crazy (see earlier examples of crazy things) and what you did to find it
3. I’ve only got so many passes so once they run out I’ll update the blog post and that’ll be the end of the freebies
4. I’ll hand out one pass per person who finds something unique (i.e. someone else hasn’t already found the same sort of thing and left a comment here)
5. Don’t go out and pwn other peoples’ systems, that’s not a great idea at the best of times!
6. If you do find something of a serious security nature, disclose it to the app owner ethically (if you’re not sure, read my views on the responsibility of public disclosure)
1. To that effect, you don’t need to name the app here if you’d prefer not to, just explain the behaviour you observed

This is all about sharing the crazy stuff that goes on just behind the scenes of the sort of apps we all use every day. For many people reading this, it’s an eye-opener; they probably weren’t aware of the extent of the crazy nor that it could be found so easily. So go forth and explore!

Incidentally, I did a similar thing last year after launching my Hack Yourself First course and it was a big hit, hope you enjoy this one too!

More Pluralsight viewing

For more walkthroughs on identifying vulnerable patterns in systems and learning how to secure them, try these:

1. Hack Your API First: Heaps of detail on what I’ve outlined above – proxying mobile traffic and finding a whole raft of common vulnerable patterns
2. Hack Yourself First: The predecessor to the above course, a big one that goes right through a whole raft of common risks in websites
3. OWASP Top 10 Web Applications Security Risks for ASP.NET: If you live in a Microsoft web world, this is the one that way down into detail about the security features within ASP.NET
4. ASP.NET Security Secrets Revealed: Heaps of info on all those little corners of ASP.NET that provide security features, often implicitly without you realising it
5. Web Security and the OWASP Top 10: The one for people who want to understand why web security is important, but may not want to get down into code-level detail

These are all accessible by Pluralsight subscribers or anyone who scores a pass by finding something crazy in an API.