Posts Tagged ‘PhoneView’

A Simple, Yet Cautionary Tale

Friday, December 28th, 2012

While we don’t normally cover web development security basics, or find much to report when poking around in iOS apps, a great example of independent investigative tech journalism related to these topics broke late last week. On Nick Arnott(@noir‘s) blog Neglected Potential, he expands on a previous post involving how data is stored within an app(nice shout-out to a personal fave, PhoneView by Ecamm,) to talk about how it communicates with whatever services it may be hooked up to. Generally speaking, SSL and PKI don’t magically solve all our issues(as comically referred to here: This is 2012 and we’re still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary,) and end users reflexively clicking ‘accept’ on self-signed cert warnings is the front lines of the convenience vs. security battle. No, you shouldn’t send auth in plaintext just ’cause it’s SSL. (Yes, you should be seeding any straggler self-signed certs on the devices in your purview so you don’t need to say ‘just for this ONE sites self-signed cert, please just click Continue’.) The fact that a banking users SSN number was being sent to the app on every communication was… surprising, and corrected immediately after the heightened interest resulting from the aforementioned blog post.

Security via public trust

Security via public trust

After the publicity surrounding the post, however, folks were reassured by getting an immediate audience with the Director of Engineering at Simple, Brian Merritt(@btmerr.) Perhaps the flaw may have been considered too contrived a process for traditional(read: an email to their security team) channels at Simple to respond in a way that satisfied Mr. Arnott before he went ahead and published his post. “If only Jimmy had gone to the police,” the saying goes, “none of this would have happened” – please do note that while responsible disclosure was attempted, the issue is with PKI and not Simple itself, and updates were added to the post when clarifications were worth mentioning to present the facts in an even-handed manner. A key take-away is the fact that there is no live, zero-day exploit going on, just the relative ineffectiveness of PKI being exposed.


Although a process can enable the snooping of traffic, by default proxy’d SSL wouldn’t be allowed to start a session

But even more importantly, the fact that observing the traffic was even possible (thanks to CharlesProxy, also recently mentioned on @tvsutton‘s MacOps blog) highlights the ease with which basic internet security can be thwarted, and how much progress is left to be made. Of the improvements out there, Certificate Pinning is one of those ‘new to me’ concept enhancements regarding PKI, which luckily already has proposals in for review with the IETF. (An interesting contender from about a year ago is expounded on at the site.) There are quite a few variables involved that make intelligent discussion of the topic difficult for amateurs, but the take-away should be that you can inspect these things yourselves, as convoluted as it may be to get to the root cause of security issues. Hopefully we’ll have easier-to-deploy systems that’ll enable us to never ‘give up’ and use autosign again.

Thanks to Mr. Merritt, Michael Lynn and Jeff McCune for reviewing drafts of this post.