By Dan Cornell
The recent AT&T / Apple data breach involving iPad 3G customers echoes some lessons we’ve been discussing with our customers deploying smartphone applications. Based on a read of the info from Goatse Security as reported by Gawker we see similar themes.
This is still breaking news, but it appears AT&T had a publicly-accessible web service deployed that would return information about an Apple iPad 3G user if it were provided with a request containing an iPad User-Agent header and a valid integrated circuit card identifier (ICC-ID for short).
Also, though this specific situation deals with AT&T infrastructure deployed to support Apple iPad devices, the lessons apply to everyone developing smartphone applications and the server infrastructure to support them – regardless of whether the target platform is the Apple iPhone or iPad, Google Android, RIM Blackberry or Microsoft Windows Mobile.
So what has this taught us?
1. Authentication and Authorization Are Crucial for Services Deployed to Support Smartphone Applications – Originally this was a problem with web pages – “hidden” directories or URLs were used to protect sensitive parts of applications. Then when AJAX and RIA rolled around the server endpoints created to support these applications had the same problem. And now smartphone applications need to call home to get to the “good” data. The lesson remains the same – if you expose a server resource that deals with sensitive data you must authenticate the user who makes the request and you must authorize that the authenticated user should have access to the information and functionality requested. We have seen most folks we work with get pretty good about this for web pages and OK about it for AJAX/RIA endpoints, but they are still missing the mark with server endpoints devoted to smartphone applications. And since the OWASP Top 10 2010 still includes it (A3 - Broken Authentication and Session Management, A8: Failure to Restrict URL Access) I guess that means the world-at-large still hasn’t gotten the original message. Protect your endpoints! If bad guys need credentials before they can attack you then you’ve certainly raised the bar. And if they don’t need to authenticate they are going to run all over you.
2. Do Not Authenticate Requests with Values that Look Random But Aren’t – We used to see this a lot with Social Security Numbers (SSNs) and we still see a lot of authentication schemes that rely on semi-public information or reasonably-guessable values. Just because a number is long doesn’t mean that an attacker isn’t going to be able to find another source of data to provide valid values. Nor does it mean they won’t be able to find a way to guess valid values. Freely-available tools like OWASP WebScarab have analysis routines that can be used to identify how much entropy exists in a series of inputs and even moderately-motivated attackers have even more sophisticated tools at their disposal. Design your authentication schemes correctly from the beginning because they can be some of the most expensive parts of systems to remediate once they have been deployed.
3. Never Trust Anything in an Attacker-Controlled Request (Especially User-Agent Headers) – To those of us in the web application security world for a while this seems self-evident, but more developers outside the “web application security bubble” need to understand that you have to assume a malicious user has full control of an HTTP request. Therefore you can’t trust anything in an HTTP header. In this case it appears as though a User-Agent header was checked to “verify” that the requesting party was an iPad which is obviously easy to bypass using freely-available tools like OWASP WebScarab. We also still see similar trust applied to HTTP cookies (which also come from an HTTP header), as well as other headers such as Referer. Making any security-critical decision based on a guessable value in an HTTP request header is a bad idea. Period.
4. Don’t Trust Your Service Providers; Test Them – This is less of a technical lesson and more of a business/risk-management lesson. Gawker makes the point that US-based iPhone/iPad users are currently required to use AT&T as their carrier. So in this case AT&T is a service provider for Apple. In the brave new world of Software as a Service (SaaS) it is easy to forget: even though you didn’t write the software, your customers are going to hold you responsible for it. Organizations selecting service providers need to make sure they are properly addressing risk associated with these providers. Controls can take a variety of forms, from table-top assessments of service provider policies and procedures to technical testing of the software before and after it is brought online. The important point for organizations using service providers is that they need to negotiate this up-front. We have been geared-up to start several assessments before our clients were stonewalled by their service providers who refused to allow testing of their services. Crappy customer service: yes. Legally-defensible for the service provider: unfortunately also yes. The advice for security folks is: keep business units from making unilateral decisions about service providers and inject yourself into the acquisition process. You don’t have to be the person who always says “no,” but you should be the person who says “let us test XYZ and if ABC happens you all have to do DEF.”
Details are still developing about this AT&T / Apple data breach, but the initial information underscores several points we have already seen with our clients developing and deploying smartphone applications. If your organization is developing applications for iPhone, iPad, Android, Blackberry or Windows Mobile please make sure your development and security teams are taking the time up front to consider the associated risks. It will save you a lot of heartache, hassle and money down the road.
[Update: Gizmodo's John Herrman posted an article discussing the true impact of the breach. This is a very balanced analysis of the impact of this current breach, but doesn't mean that smartphone developers shouldn't take note.]
Contact us for help developing secure smartphone applications and dealing with risk in your application portfolio.
--Dan
dan _at_ denimgroup.com
These are good lessons for anyone writing a public-facing service of any sort, not just for Smartphones. Thanks for the post -- Joel.
Posted by: Joel Shepherd | June 10, 2010 at 12:25 AM
Great point! Smartphone apps have their own set of security issues _and_ they also require organizations to deploy a whole bunch more of the same stuff they've been deploying for a while (web pages, web services, etc). Problem is a lot of organizations re-make a bunch of the same mistakes made before.
--Dan
@danielcornell
Posted by: dancornell | June 10, 2010 at 12:43 AM