Risk
6/24/2010
04:54 PM
Connect Directly
RSS
E-Mail
50%
50%

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

Gaffes offer lessons for IT security organizations, according to analysts

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.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3341
Published: 2014-08-19
The SNMP module in Cisco NX-OS 7.0(3)N1(1) and earlier on Nexus 5000 and 6000 devices provides different error messages for invalid requests depending on whether the VLAN ID exists, which allows remote attackers to enumerate VLANs via a series of requests, aka Bug ID CSCup85616.

CVE-2014-3464
Published: 2014-08-19
The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) 6.2.0 and 6.3.0, does not properly enforce the method level restrictions for outbound messages, which allows remote authenticated users to access otherwise restricted JAX-WS handlers ...

CVE-2014-3472
Published: 2014-08-19
The isCallerInRole function in SimpleSecurityManager in JBoss Application Server (AS) 7, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 6.3.0, does not properly check caller roles, which allows remote authenticated users to bypass access restrictions via unspecified vectors.

CVE-2014-3490
Published: 2014-08-19
RESTEasy 2.3.1 before 2.3.8.SP2 and 3.x before 3.0.9, as used in Red Hat JBoss Enterprise Application Platform (EAP) 6.3.0, does not disable external entities when the resteasy.document.expand.entity.references parameter is set to false, which allows remote attackers to read arbitrary files and have...

CVE-2014-3504
Published: 2014-08-19
The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Dark Reading continuing coverage of the Black Hat 2014 conference brings interviews and commentary to Dark Reading listeners.