AT&T’s failure to protect iPad e-mail addresses spotlight the kind of security issues facing enterprise smartphone deployments, according to a company that focuses on application security.
Enterprise security staff ought to take away two lessons from the AT&T affair, says Dan Cornell, CTO & co-founder of Denim Group, which works with companies to secure application, including a growing number of smartphone applications. He offered his comments in a weblog post on the company’s Website.
Can You Listen to What I Mean? Polycom Delivers HD Voice: Download now
iPad rivals slideshow
The AT&T breach was initially exposed by Gawker.com, drawing on information from a hacking group calling itself Goatse Security. The hackers learned that they could present an HTTP request to AT&T’s public Net site, with an iPad User-Agent header as well as a valid Integrated Circuit Card Identifier (ICC-ID), which uniquely identifies a SIM card.
In response, the Website returned information about an Apple iPad 3G user, specifically, the e-mail address submitted by that user when activating the iPad according to Apple’s requirements.
This breach was limited to iPad 3G users (though these included a high-profile group drawn from entertainment, high tech, government and the military) and apparently only the e-mail address was returned. The danger seems to have been limited to the chance of being spammed, or possibly subjected to phishing assaults.
According to the original Gawker story, the Goatse Security hackers “notified AT&T.” The carrier, in a brief written statement on which a spokesman declined to expand, flatly denied this. “The person or group who discovered this gap did not contact AT&T,” the statement read. In lieu, ““AT&T was informed by a business customer on Monday [June 7] of the potential exposure of their iPad ICC IDs.
The only information that can be derived from the ICC IDs is the e-mail address attached to that tool.” The carrier “essentially turned off the feature that provided the e-mail addresses” and that was done by Tuesday.
According to Cornell, there’s three lessons to be learned from this, in generating secure smartphone applications.
First, effective authentication and authorization are crucial if you are exposing to users any server resource that deals with sensitive information. Users must be authenticated as being who they claim to be, and then authorized to access the information being requested.
“We have seen most folk they work with get nice about this for Web pages and OK about it for AJAX/RIA [Rich Web Applications] endpoints, but they are still missing the mark with server endpoints dedicated to smartphone applications,” he writes. “Protect your endpoints! If bad guys need credentials before they can assault you then you have definitely raised the bar. And in the event that they needn’t authenticate they are going to run all over you.”
Second, make definite you authenticate requests with values that are truly random. AT&T’s lapse was due in part, according to the hackers, because the ICC-IDs were basically guessable. Watch out for relying on values that “look random but are not,” Cornell says. “We used to see this a lot with Social Security Numbers (SSNs) and they still see lots of authentication schemes that depend on semi-public information or moderately guessable values,” he writes.