You're not counting on your app store, are you?

Today's mobile app stores, like Apple's App Store (via iTunes), review the software in their stores before the public can download them. That curation process, however, is not without its limitations -- and as software developers, we absolutely must not ever rely on the curation process to spot security defects in our apps.

Much has been said about Apple's own App Store, both good and bad. Whatever your preference, their  App Store has undoubtedly the most rigorous app review process in the mobile app store business, such as it is. Developers are required to conform with their guidelines in order for their apps to get approved and become available for consumers to purchase.

But even that rigorous review is not in any way intended to be a security review of your apps. Make no mistake about it, Apple is not in the business of ensuring your app is secure.

So then, what do they do? Let's explore a bit -- with the understanding that I have no inside knowledge at Apple, and I'm basing this on my observations and readings.

• Stability. They verify the app loads and runs as described.
• Functionality. Does the app perform the advertised functionality?
• Play by the rules. Does the app conform to Apple's published API standards? More to the point, is your app using any unpublished APIs, which is perhaps the biggest no-no on the app store.
• Policies. Does the app conform to Apple's policies (good, bad, or otherwise)?

Now, I admit that the above is probably a gross over-simplification of what they actually do. I'd expect they load the app in a controlled test environment. I'd expect they run the app using some profilers and such to look for memory leaks and that sort of implementation faux pas.

But, by and large, if your app conforms to their published APIs and their policies, it's good to go.

OK then, so what sort of things would that process miss? From a security standpoint, pretty much everything. Some of the biggest shortcomings that I would never expect Apple (or others) to find in their review process include:

• Local storage of sensitive data. As long as your app uses published APIs for file input/output, you can store whatever you want to, however you want to. Want to put your users' credentials into a plaintext SQLite database? No problem.
• Secure communications. Again, use published APIs (e.g., NSURL) and the app will fly right on through the review process, irrespective of whether you use SSL to encrypt the network data. Want to send your users' username/password credentials in a JSON bundle to your server's RESTful interface, without any encryption at all? No problem.
• Authentication to back-end services. Published APIs, blah blah blah... Want to authenticate your users against a locally stored username and hashed password? No problem.
• Session management on back-end services. Want to use easily guessable, sequential numbers for your users' sessions? No problem.
• Data input validation. Want to allow untrusted data in and out of your app, without ensuring they're safe from SQL injection, Cross-site scripting, etc? No problem.
• Data output encoding/escaping. Want to pull some data from a database and send it straight to a UIWebView without encoding it for the output context? No problem.

That list can go on for a long time. Apart from these shortcomings, the app review process is just fine. :-)

To Apple's defense, reviewing an app for the sorts of things I've listed here takes a high level of knowledge of the app itself, the business function it provides, the sorts of data it handles, etc. These are things that cannot and must not be performed by a team with no knowledge of the app, like an app store review process.

No, to review an app for common shortcomings like these must be done by someone with deep knowledge of the app. That should happen within the app development team, perhaps with support from an external team to perform some rigorous security testing.

No matter how it's done, the reviewers simply must understand the app and its business. Without that knowledge, no review can be adequate.

We'll discuss ideas for how to do reviews like these -- and prevent the security flaws in the first place -- at our Mobile App Sec Triathlon in San Jose, California on 5-7 November. Join us and let's discuss.

Cheers,

Ken van Wyk

Mobile Brings a New Dimension to the Enterprise Risk Equation

In yesterday's blog we looked at Technical Debt, and how its infosec's habit to lag technology innovation. In the big picture, this approach worked pretty well in the Web, early web security was pretty poor but early websites were mainly proof of concepts and brochureware. As the value of the websites increased, infosec was able to mostly get just enough of the job done and played catchup for the whole decade.

But this catchup approach does not work in Mobile, the first apps are not brochureware, they are financial transactions, medical decision making tools, and real dollars flowing through the apps on day zero! That's 180 degrees different from how the Web evolved, with the Web we waded in the shallow end for years, with Mobile we are diving off the high dive with 1.0.

This risk profile should embolden infosec teams to get active way earlier in the process and to be more prescriptive. But it does not stop there, the nature of the engagement has changed as well, case in point:

The personal data of about 760,000 people was temporarily leaked onto the Internet through an address book application service for smartphones, information security company NetAgent Co. reported.

The Tokyo Metropolitan Police Department is set to launch an investigation after being informed of the case Saturday by Tokyo-based NetAgent. The application developer said the data leaked online has been deleted.

The latest version of the application, Zenkoku Denwacho (Nationwide Address Book), has been distributed for Google Inc.'s Android operating system for free since mid-September. It enables users to search information listed in a major address book developed by Nippon Telegraph and Telephone Corp., according to NetAgent.

But the application is also designed to send personal data stored in smartphone users' address books, including names and phone numbers, to a rental server.

Such information temporarily became available through the Internet mainly to users of the application, which at least 3,300 people are estimated to have downloaded.

Here we see another dimension to the risk equation for Mobile that enterprises have little experience facing- they are not just providing a browser front end, they are shipping code (apps) to users. The enterprise security team now needs to not only care about the site working on Firefox, IE, and Chrome. They need to care about a whole array of platform and device specific security considerations; ensuring the application does not introduce vulnerabilities, inadvertantly steal or leak data, location, addresses, and more. And its all specific to each Mobile OS.

Because Mobile is a Balkanized environment, platform specific Security architecture and guidance is required to get the job done. This means more up front work, but its essential to avoid mistakes like apps that can leak data or provide entry points for attackers to the Mobile app and data (bad) or enterprise gateway and backend (worse).

Its time for Infosec to step up


Patch and pray is not good enough, enterprise security teams must roll up their sleeves, do the work required to support security services for iOS, Android apps, data, and identity. Nothing is perfect but there are absolutely better and worse ways to implement here, Infosec *should* play a leading role, as the grown up, in practically navigating these choices.

Take a hard look at the Use Cases your company is going Mobile with, this isn't beta brochureware, this is real data, real transactions, real identity, real risk, and real new technology. Now is the time for Infosec to get smart on iOS and Android, and build security in.

**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.

Line in the Sand on Subprime Security- Mobile Apps Can't Afford to Take on Technical Debt

If there is one thing that's crystal clear in Infosec its that Infosec lags software innovation. Its a field where we are always playing catch up and the important question tends to be - how fast can we catch up?

Because innovation outpaces security, Infosec has been a passive bystander shuffling debt issuances around like someone processing subprime mortgages and rating it Triple A when the first payment cannot even be made. The industry ships apps everyday with substandard access control that do not reliably authenticate or authorize users, much less deal actively malicious actors.

Technical debt measures the necessary work that does not get shipped in a release. Taking on too much debt is like borrowing too much money, it might work but once things begin to go against you its hard to recover because you are not in a position of strength. As Warren Buffett says, "You don't know who is swimming naked until the tide goes out."

Its important to note that Technical debt for security is not a passive thing, there are people actively looking to find and exploit your Technical debt.

As of now, the Information Security Technical Debt Clock (appropriately implemented in Javascript) shows 17 years (or 6,517 days) since the internet's foundation security architetcure of Network Firewalls and SSL were deployed. Since then we've been waiting for identity, authentication, authorization, and logging standards (de facto or otherwise).

The reason why playing catch up is not good enough in Mobile is one that will be familiar to my clients - the Mobile Use Cases are too important to screw up.

The security industry skated by the whole history of the Web on a security architecture past its sell by date, but at first it did not matter. Go way back to the mid 90s, what kind of apps were being deployed? Mostly brochureware. It took years to get to dynamic, data driven sites, and then years to get to profitable, transactional sites (pets.com anyone?). Point being - early Web was cool as hell, but it was a giant science project followed by a hype bubble. The fact that Infosec did not move quickly enough to deal with the security issues was too bad, but at the same time not a systemic failure because the arly Web Use Cases were low risk brochureware.

Most companies just dipped their toe in the water, and security incrementally figured out how to deal with SQL Injection, XSS, and so on in an iterative process. But there was time to do this in most cases.

Mobile is different

The first generation Mobile Use Cases are most certainly not dipping toes in water, they are diving in head first (and perhaps a lifeguard may not be present)! Doctors with iPads, brokerage applications, and pretty much the whole remote work force pinging your mainframe from who knows where. This has the makings of a bad cycle of events for security. Infosec is used to playing catch up because the technology moves fast but the business will take awhile to roll things out. Not in Mobile, the backend hooks are largely already there, just need to find the right Web services to call and write an iOS and Android front and dive right in the deep end.

Wait and see what happens is not good enough any more, Infosec needs to act now and get in front of the Mobile security issues. Take a hard look at the Use Cases you are deploying on Mobile, this is 1.0 technology running High Risk Use Cases, your Mobile Security architecture and implementation cannot be patch and pray.

Mind the Gap: Compare the risk level of what's being deployed to the robustness and assurance of your mobile security. Its time to invest: learning ways towards building a more resilient security foundation.
**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.

Is SSL adequate for your iOS app?

How do you secure your iOS apps' network connections? Is it sufficient to simply use HTTPS in an NSURL object? The short answer is it depends. For sure, some recent attacks have eroded the trust we can place in the venerable SSL or TLS standards, but we're also not ready to just throw them out either.

It turns out you actually have numerous options available, depending on your app's needs. For starters, if you're using NSURL to make your HTTP connections, you can quickly change it to an SSL encrypted network session by simply changing the URL to HTTPS://...

That should provide you with basic protection against eavesdropping (and a few other network nasties) quickly and easily. But is it enough?

To understand that, let's consider a bit more what actually happens in an SSL protected network socket. When iOS (via NSURL) sees an SSL certificate from a server, it verifies two things: 1) is the certificate signed by a root certificate authority (CA), and 2) does the server's name (via DNS) match the name presented in the SSL certificate? Now, that combination might sound adequate, but there is actually a loophole or two remaining.

A sufficiently resourced adversary with access to the soft under belly of DNS as well as access to one or more CAs can still trick your app into accepting a connection you wouldn't otherwise want. In an extreme case, this could result from a successful man in the middle (MITM) attack.

So, for some cases, we might want to do more than just SSL. We might, for example, want to verify that a specific CA signed the server key. We might want to check that it is precisely the right server key that has been presented, using "certificate pinning".

Each of these things is achievable, but they require us to dig deeper than just using USURL with an HTTPS URL. They also have pros and cons -- cert pinning, for example, isn't going to work with many network proxies that a lot of corporate LANs require.

We'll discuss these options, along with code examples, at our Mobile App Sec Triathlon in November. Hope to see you there, ready to discuss so you can best understand what course of action is best for your app and its users.

Cheers,

Ken

What's In your Android Security Toolkit, Part 4

This is the fourth in a series of posts focused on building an Android Security toolkit. So far we have looked at access control services and defensive coding, which are necessary for the Mobile app. but no Mobile app is an island.

Mobile apps can have lots of communication channels, such as SMS, NFC, and GPS. If used, each of these presents the enterprise a new set of challenges to deal with, protocols and threat models that the enterprise security team likely has not worked in depth with before.

On top of that, the Mobile app usually needs to connect back to the enterprise or Cloud via Web Services. Many enterprise mobile projects begin by saying something like "we have web apps and we have web services, this is nothing more than sticking that little sucker (the mobile client) as a new front end and we are done." Thinking that a mobile app is no different from supportin, say, Firefox is to miss the core of mobile. I have seen this repeatedly and it leads you down the wrong path.

Some of the differences include that mobile devices are ot connected per session (like a web app), they are occassionaly connected and those connections drop. This leads to caching and other usability enhancers. You can expect that a mobile middle tier (not just another front end on existing portals) will be required to manage optimizations and resolving sessions, cache and routes. On top of that, the enterprise is in a position of delivering not just data, but delivering code to the device. Its no longer a case of riding the rails of Chrome, IE or Firefox. The enterprise is now in the business of packaging, deploying and testing client software.

The communication between the Mobile app and the Mobile Web service requires layers of protection. Even the basics here, like access control, are fraught with challenges.

To navigate the Venn of Mobile Security, look outside the device. How will the device be manageed? How is access controlled when calling the Web services? What identity is used? How are the Web services protected? How is it authorized on the server side? These services are crucial to enabling the mobile app to work in a real enterprise deployment. The requirements are not all platform specific but they all create platform specific requriements for the Android developer to deal with. Think End to End.

**
Come join two leading experts, Gunnar Peterson and Ken van Wyk, for a Mobile App Security Training - hands on iOS and Android security, in San Jose, California, on November 5-7, 2012.