“Whose problem is this? Whose problem is a vulnerability in an app? Is it the app developers? Is it the service provider of the operating system? Or is it the distribution center of the application?”
These aren’t questions presented to an expert panel by attendees at the Cloud Security Alliance Summit at RSA in San Francisco this morning. These are questions coming from that panel – specifically, from a professional security analyst whose firm openly experiments with app store security, including from Google’s app stores for Android and Chrome OS.
Pictured above, from left to right: Philippe Courtot, CEO, Qualys; Don Godfrey, security consultant, Humana; Matt Johansen, Threat Research Center manager, WhiteHat Security; Patrick Harding, CTO, Ping Identity.
Matt Johansen runs the Threat Research Center for WhiteHat Security, a private analysis firm that specializes in determining the relative security characteristics of Web sites and Web apps on behalf of their proprietors. Sometimes their research extends outside the security of the app itself, and into the environment in which it’s distributed and propagated.
Speaking a one of a powerhouse panel assembled by Qualys CEO Philippe Courtot, Johansen related some of WhiteHat’s experiences with testing the fringes of Google security. He noted that consumers’ expectations of responsibility are based on consumers’ history – when someone buys tainted food, they blame the supermarket, even though legally the farmer may be at fault. Maybe there should be some sort of code review process at Google, he suggested.
Maybe. “When I was doing some research on the Chrome OS, we uploaded an extension to the Chrome Web store called, ‘Malicious Extension,'” admitted Johansen. “There was absolutely no code review process there at all.” The app contained fake buttons which read, “Steal cookie,” and the like. For a while, it stayed available for download until WhiteHat took it down. But before that, he approached Google to demonstrate the problem and to ask them the string of questions which led this article.
“I’ve never gotten the same answer twice from anyone that I’ve asked,” he remarked. “It’s an interesting problem, and I think we’re going to see it more and more. One of the scariest facts about it is, the iPad didn’t exist more than two years ago… [So] we don’t really know the answer to these problems. Who’s problem is it to fix this vulnerability in an app that you’re installing on your operating system, and that has permissions that it maybe shouldn’t.”
Everyone who’s installed an app on a smartphone has seen the permissions screen which informs the user what kinds of information may be shared. A banking app should be expected to communicate a certain quantum of personal data, specifically with the bank. That’s if the app works properly. If it doesn’t, it may share something else instead. Or it may share the right data with the wrong source. If that ends up compromising the integrity of someone’s bank accounts, who’s responsible? It’s such a new industry, Johansen pointed out, that the question really hasn’t had time to be answered before the technology behind it became suddenly ubiquitous.
The Cloud as Agitator
To an ever-greater extent, the mobile app serves as a facilitator between a device and a cloud-based service. It’s a “cloud” service, as opposed to a conventional Web server, because its structure is virtual, its location is variable, and the resources it provides are made to appear local – as though the user installed them on his phone.
That doesn’t change everything, though, argued panelist and Ping Identity CTO Patrick Harding. “The cloud doesn’t solve developers building insecure applications,” Harding told the RSA audience Monday morning. “They’re going to do that no matter what. What people are finding, though, is that SaaS applications [developers] specifically have a business incentive to seriously write secure applications. But as you drift down the stack, so to speak, the risk goes up. If you talk about IaaS and people deploying to the cloud there, you’re not getting the same level of analysis and control as somebody like a Salesforce or a Google, or someone like that, might have.”
Matt Johansen may have a different perspective. One service WhiteHat provides, for example, is asset discovery – taking inventory of a customer’s digital resources. A Web app serves as the public doorway for data stored elsewhere, he explained. With respect to a vulnerability management job, WhiteHat often finds that its clients have no clue how many Web apps they have, nor how many Web sites they need the firm to analyze. “That seems to be one of the harder questions to answer for a lot of people,” said Johansen, “and I think that’s very telling. I think that’s kinda scary. If you have a footprint on the Internet with your applications, and you don’t even know the size of them, how are you going to manage every entry point into your data when you don’t even know where the doors are?”
Ping’s Patrick Harding took the opportunity of speaking before the CSA Summit to stomp just a bit further on one of his pet peeves: the growing uselessness of passwords as lynchpins for authenticity. Cloud computing only exacerbates this problem, Harding believes, because cloud-based resources typically require authentication.
“I actually think that passwords are the Achilles’ heel of cloud security,” Harding said, striking a familiar theme. “For all the money that people are going to spend on encrypting their data and putting Web app firewalls in front of them… if I can get your password from any one of the applications that you use, I’ve got instant access to all that data, essentially.”
Harding noted that in his research, Web apps that use a person’s e-mail address as her identifier (Google Apps being the most prominent of these) tend to provoke that person to utilize the same password for each app. One very dangerous discovery that Ping made, in conjunction with Google, is that when corporate e-mail addresses are used to identify apps users, the apps password ends up being the e-mail password.
“With the cloud, what you start to see is a lot more applications available for users. It’s that much cheaper, it’s that much quicker to deploy applications out in the cloud,” stated Harding. “So there’s just going to be more of them. Every one of those applications is going to end up being accessible from my laptop, from my mobile phone, from my iPad… it could be any point at any time. That whole anywhere, anytime access is just ending up forcing the exposure of login forms to the outside world.”
Grafting Identity Back Onto APIs
One class of resource whose architects often eschew the need for identity and authentication, is the API. A growing number of Web apps are actually remote clients for open APIs, as the panel acknowledged. Many architects believe anonymous access is a necessary factor for open APIs, and that security is a matter best addressed by security architects – API architects need to focus on providing the answer, not questioning the questioner.
I asked the CSA panelists, if they were indeed the ones tasked with securing open APIs, how do they approach this task without introducing identity back into the picture, and wrecking the developers’ vision of beauty through anonymity. Ping Identity’s Patrick Harding commended me for asking a question that answered itself.
“API architects are in the wild, wild west,” Harding responded. “They love it because it’s simple and easy, and completely forget about securing them in any way at all. The only standards that exist in the REST world for security, up until the last two years, was HTTP basic, and SSL. The same stuff we’ve had for, I don’t know, 20 years. It’s crazy.”
OAuth, which we’ve talked about here in RWW, does address one method of trusting someone else with the task of authenticating and authorizing the user, thus giving API developers one way to take the subject off their hands without ignoring security altogether. Harding suggests more API architects look into OAuth. “It doesn’t speak to, ‘Is my API secure, per se?'” he noted. “How do I know that SQL injections aren’t being slapped through that API effectively, via JSON messages?”
WhiteHat’s Matt Johansen acknowledges OAuth adds identity to the mix, but endorses it as what needs to be done. “Tokenization and checking the source and destination… is adding identity to the problem,” he said, “but it is helping solve it.”
The Cloud Security Alliance holds its annual Summit event as part of the RSA Conference, complete with its own panel session, keynote speaker, and innovator awards.
