AT&T iPad Breaches Are About App Security, Not Mobile Devices, Experts Say

The recent breaches of Apple iPad customer data at AT&T have drawn attention to security issues in both the mobile device and service provider spaces. But after analyzing the leaks, analysts say the lessons to be learned are not related to mobile or service vulnerabilities at all -- they're lessons in the links between Web applications and back-end databases.

"Mobile computing is no longer about mobile computing -- it's really all about the Web," says Mandeep Khera, chief marketing officer for Web app security company Cenzic. "Most people don't realize that -- even most telecom companies don't realize it -- so they're focusing on the hardware piece [of the breaches]. But if you think about the end-to-end cycle of a mobile computing service -- from acquisition to processing orders to customer service and all of that stuff -- it's all on the Web. It's all based on Web applications."

Earlier this month, AT&T and its partner, Apple, found chinks in their Web application security armor when more than 100,000 iPad user accounts were exposed due to a business logic flaw in a public AT&T Web application.

Not long after issuing apologies to customers over the iPad incident, Apple suffered a second privacy breach when users reported accessing other customers' private information while preordering the latest iPhone through AT&T's website.

AT&T and Apple claimed they couldn't replicate the problem, but security experts, such as Jeremiah Grossman of WhiteHat Security, claimed the issues sounded suspiciously like session exhaustion, an behavioral anomaly that occurs when an application is overloaded and begins to run out of session IDs.

Observers say both incidents likely involved poorly deployed Web applications that put sensitive back-end data at risk, giving nonauthorized users access to database information to which they shouldn't have been privy.

"In the recent case of AT&T and Apple, their incompetence at building scalable and secure infrastructures -- or the incompetence of the vendors who built their systems -- is on display for the whole world to see," said Phil Lieberman, CEO of Lieberman Software. "Had they used off-the-shelf load-testing tools, they would have known about their scalability problems long before their public and embarrassing debacle. The nature of their security problems can be traced to taking shortcuts with their website design and not performing rigorous code reviews and penetration testing."

According to Ted Julian, security analyst at Yankee Group, the AT&T embarrassment can definitely be seen as a cautionary tale to all organizations -- telecom or not -- to pay closer attention to the security of Web applications and their relationships to sensitive data stores.

"Although, frankly, if that's news to any security professional they should be changing careers," he says.

Because such issues are common knowledge, it's surprising that a well-known giant like AT&T still failed to properly secure Web applications that tapped into the bread-and-butter of its wireless customer base -- its Apple clients, experts say. According to Khera, it means the industry needs another wake-up call.

Time and time again, Cenzic sees new customers and prospects that leave database information exposed through the flawed Web applications that are meant only to stream that data to legitimate users -- but end up exposing it.

"The database is static. As it sits there, it has to be available. You can't encrypt it to the level where it can't be displayed to the users," Khera says. "So how do you secure it? The only way is to secure those Web applications."

What should enterprises be doing to avoid a similar fate? According to Khera, one step is to get developers trained in security principles so they aren't inadvertently leaving data stores flapping in the wind via business logic flaws, vulnerabilities to cross-site scripting, vulnerabilities to SQL injection attacks, and so on.

"Some of them might even be looking at cross-site scripting and SQL injection," Khera says. "But things like session management-types of vulnerabilities -- people don't even think about those. I think they need to go through training and have at least the most critical vulnerabilities in mind when delivering the code on Web applications -- and build that into the project plan. Personally I just don't think companies are doing that, and I think that is the crux of the problem."

Beyond training, developers also need the right tools to test for vulnerabilities and fix them quickly, experts say. That means leveraging vulnerability scanning tools that look for flaws in applications during production and after they go live. It also means using blocking tools, such as Web application firewalls, that can mitigate vulnerabilities found in live applications until developers can go back and patch them.

According to Brian Contos, chief security strategist for Imperva, organizations should pay special attention to database activity coming from Web applications.

"Web applications and databases, they're so dynamic," Contos says. "They're not like a network firewall, where you can allow Telnet or disallow Telnet, block a port or open up a port. It's just not that binary."

While developers should run code reviews and vulnerability assessments, these will provide only a snapshot into the interaction between Web apps and databases, experts warn.

"At the end of the day, you need something that's up and running 24/7, monitoring what's going on between the Web application and the database, and how users are interacting with their data," Contos says. "That will tell you what's happening and how people are using your database -- as opposed to what you expected to happen. Sometimes those can be two very different things."

A good vulnerability and mitigation tool will give DBAs and security personnel a common mechanism to look at when they are deciding how to lock down enterprise data, experts say.

"They can say, 'Hey, let's look at the alerts from our database firewall -- or our Web application firewall or whatever solution it is that we're using -- and let's talk through it together,'" Contos explains. "Then we can say, 'This is how this attacker was trying to exploit us, and here are the controls can we put in place.'"

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.