Attacks/Breaches
11/15/2013
12:46 PM
50%
50%

4 Lessons From MongoHQ Data Breach

Security experts urge companies to implement two-factor authentication, VPNs, and graduated permission levels to better protect customer data from hackers.

How could MongoHQ have prevented last month's breach that gave an attacker access to the company's customer database and its customers' social media accounts?

The breach of MongoHQ -- a database-as-a-service provider that provides hosted instances of MongoDB -- began on October 27, when a hacker accessed the site's service infrastructure. "The MongoHQ password of one of MongoHQ's employees was stolen," said Joel Gascoigne, CEO of social media account management company Buffer, who helped trace back the intrusion after someone began posting spam via the Facebook and Twitter accounts of Buffer's customers.

By October 28, MongoHQ warned its customers that it had detected "unauthorized access to an internal support application using a password that was shared with a compromised personal account." After detecting the breach, to the company's credit, it immediately reset all customers' passwords, began working with the FBI, and hired a third-party digital forensic investigator.

The speed and seriousness of the company's response and warning, as well as its promise to make specific security improvements to prevent a breach recurrence, earned the company plaudits from information security experts.

Even so, here are four ways the company might have prevented the breach altogether:

1. Two-factor authentication
In the wake of the breach, MongoHQ CEO Jason McCay promised that support applications would remain offline until "we have [a] functioning, enforced two-factor authentication" system. Once that was in place, even if an employee's password were to be stolen, an attacker couldn't use it to access the site. Instead, they'd have to find some other, more difficult way to access the site, for example by exploiting a web application vulnerability.

Never underestimate the power of a good two-factor authentication system -- or making that a "must have" buying decision for any product -- especially when handling or safeguarding large amounts of customer data. For example, this week's hack of MacRumors that resulted in 860,000 emails and passwords being stolen could have been prevented if the Apple rumors and news website had been able to use two-factor authentication to secure administrator access to the vBulletin software that runs its online forums. Unfortunately, however, the vBulletin software doesn't currently offer that capability.

2. VPN access for support portal
One contributing factor to the MongoHQ breach, according to a blog post from Imperva security researchers Barry Shteiman, Michael Cherny, and Sagie Dulce, was that "a support application was accessible through the Web and not behind a VPN."

As with two-factor authentication, using a VPN would have added another layer of security that a would-be attacker would have to defeat before gaining access to a targeted site.

On that note, MongoHQ's McCay said that after the breach, the company's "employee-facing support applications" would remain disabled until the company created a system that restricted access solely to VPN connections. "Our backend applications, supporting services, and utility tools will be moved into a private network and require employee VPN access," he said.

3. Restrict employee access to customer accounts
Do customer service personnel need a "god mode" for accessing customers' accounts? That was the capability given to MongoHQ's support personal, via an "impersonate" feature that allowed them to browse customers' data and manage their databases for troubleshooting purposes.

But in the hands of attackers -- or a potential malicious insider -- that feature provided carte blanche access to sensitive information. "Hackers logged into the main admin dashboard of MongoHQ and were able to use the 'impersonate' feature to see all of Buffer's database information," Buffer CEO Gascoigne said. "Through that, they wrote a script to steal our social access tokens and post spam messages on behalf of our users."

Of course, some service personnel may require direct access to customers' data. But McCay said MongoHQ has now created "a system of graduated permissions, tested thoroughly, that allows only the minimum needed privileges to support personnel based on role," thus curtailing outright most support access to sensitive information.

4. Know what customers expect, then work backwards
Another useful test for the effectiveness of your business's security program is to ask: "What would customers expect?"

Or as the Imperva reearchers put it: "Were MongoHQ customers aware that their sensitive data was visible to the MongoHQ support application? Do you know who can access your data? How is it stored? Can it be copied? These are all questions that are all too often forgotten, especially for young startup companies eager to build applications and avoid dealing with security and management costs."

Another excellent information security question to ask is: "Where are our crown jewels?" Then ensure that a greater portion of your security budget goes to securing that ultra-sensitive information.

In the case of MongoHQ, for example, while the investigation is still ongoing, "currently, it appears that the unauthorized user was scanning for social media authentication information for spamming purposes, and probing for financial information in customer database," said McCay. In other words, at least for that company, the Twitter and Facebook access credentials and financial information it's storing are a high-priority target.

Going forward, thanks to revisions introduced with the Payment Card Industry's Data Security Standard (PCI DSS) version 3, businesses such as MongoHQ that have customers that must comply with PCI will need to put these types of details in writing. Under PCI version 3.0, which will take effect at the beginning of January -- although businesses will have until the end of 2014 to comply -- "service providers are now accountable for protecting the data of their customers," the Imperva researchers said. "Data center security needs to be out in the open, especially 'up in the cloud.' "

Advanced persistent threats are evolving in motivation, malice and sophistication. Are you ready to stop the madness? Also in the new, all-digital The Changing Face Of APTs issue of Dark Reading: Governments aren't the only victims of targeted "intelligence gathering." Enterprises need to be on guard, too. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

CVE-2014-7142
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (crash) via a crafted (1) ICMP or (2) ICMP6 packet size.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?