Attacks/Breaches
10/30/2013
11:42 AM
Connect Directly
RSS
E-Mail
50%
50%

MongoHQ To Customers: Change Database Passwords

Following security breach, MongoDB hosting firm advises customers to change database passwords as it locks down systems and bolsters security defenses.

After an attacker gained unauthorized access to a MongoHQ support system, the MongoDB hosting service has advised all customers to change their database passwords.

"On October 28, 2013, we detected unauthorized access to an internal support application using a password that was shared with a compromised personal account," read a MongoHQ Security Breach advisory published Tuesday by Jason McCay, the CEO of MongoHQ. "We immediately responded to this event by shutting down our employee support applications and beginning an investigation which quickly isolated the improperly secured account."

In response to the breach, McCay said that every internal MongoHQ system has been locked down, and many remain disabled. The systems are being brought back online only after associated credentials have been reset and a third-party audit verifies both that old credentials no longer work. Going forward, support personnel will have access only to the minimum amount of information necessary to do their job. McCay added that a two-factor authentication system has also been put in place to secure access to all of the company's email and backend systems.

"In handling security incidents, MongoHQ's priorities are to halt the attack, eliminate the control failures that allowed the attack to occur, and to report the incident candidly and accurately to our customers," he said. "As one of the founders of this company and a part of this great team, I hoped to never have to send this notice. ... We are taking all appropriate steps to mitigate this risk and protect you."

[ Syrian Electronic Army targets President Obama's social media accounts. Read Syrian Hackers Attack Obama's Website. ]

MongoHQ is a database-as-a-service provider that was founded in 2011 to provide hosted instances of MongoDB. Meant to echo the word "humongous," MongoDB is a free, open source and cross-platform database system that's designed to be document-oriented. A number of organizations employ the technology, including Craigslist, MetLife, SAP and the European Organization for Nuclear Research, better known as CERN, which employs the database system to collect data from the Large Hadron Collider. (To be clear, none of those organizations have publicly stated that they're MongoHQ customers.)

What risk do MongoHQ's customers now face? McCay said that the support application, which the attacker accessed, includes the ability to "impersonate" a customer -- to browse customers' data and manage their databases -- for troubleshooting purposes. By accessing the support application, McCay said, the attacker could have obtained customer-related account information, including lists of databases, email addresses, and bcrypt-hashed user credentials. Still, the use of bcrypt -- a password-hashing algorithm that's earned plaudits from encryption experts for being tough for would-be password crackers to attack -- is a point in MongoHQ's favor, because it's bought the company time to block any attacks that might result from cracked credentials.

McCay noted, however, that the attacker also appeared to directly access some customers' hosted databases. "We've conducted an audit of direct access to customer databases and determined that several databases may have been accessed using information stored in our account database," he said. MongoHQ is notifying affected customers directly.

Due to the breach, McCay advised all customers to change their database passwords, either through the MongoHQ website user interface or by connecting directly to the database. Changing the access credentials, he noted, will require an update to any applications that connect to your database as well. He also recommended that all customers check their database and MongoHQ account for unused, expired or invalid usernames and eliminate them.

MongoHQ's data breach response may have also affected customers whose MongoDB systems are tied to Amazon Web Services. "As a precaution, we took additional steps on behalf of our customers to invalidate the Amazon Web Services credentials we were storing for you [for the purposes of backups to S3]," said McCay. "While this prevents the abuse of your AWS credentials by any malicious party, it may have resulted in additional unintended consequences for your AWS environment if you were utilizing the same AWS credentials for other purposes. We apologize for any inconvenience, and we have provided a list of impacted AWS credentials to AWS Security."

An Amazon Web Services spokeswoman said via email that the company is offering premium AWS support for MongoHQ users affected by the breach "as a courtesy to our customers."

Of course, no one -- businesses or their customers -- wants to become data breach victims. But what businesses do in the aftermath of a breach can make a world of difference for minimizing any fallout suffered by their customers. So far, MongoHQ's post-intrusion response -- detailing what happened, the steps it's putting in place to prevent a reoccurrence in the future, bringing in outside information security investigators, and proceeding in a rigorous manner to assess systems before bringing them online again, all less than 24 hours after the breach was detected -- appears to stand as a model for how businesses that do suffer a data breach should respond.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
D. Henschen
50%
50%
D. Henschen,
User Rank: Apprentice
10/31/2013 | 2:15:48 PM
re: MongoHQ To Customers: Change Database Passwords
This is an unfortunate incident for MongoDB because it will enable unscrupulous competitors to try to tar the database with the brush of this incident. It's clear it's the hosting provider's security, not inherent database security, that was compromised, but that won't stop detractors from flashing headlines and adding to the FUD.

We've had headlines here on InformationWeek.com including "Does NoSQL Mean No Security?" http://ubm.io/17uWrZK that have raised this issue before, discussing JavaScript injection and JSON injection as the NoSQL equivalent of SQL injection.

NoSQL database vendors have added a lot of security provisions since that 2012 article, but I'm no security expert and would refer you to DarkReading.com for the latest on NoSQL security. I've heard relational incumbents throw security cold water on NoSQL in general, and this incident will just add heat without shedding light on the real question of relative security.
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-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3541
Published: 2014-07-29
The Repositories component in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to conduct PHP object injection attacks and execute arbitrary code via serialized data associated with an add-on.

CVE-2014-3542
Published: 2014-07-29
mod/lti/service.php in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to read arbitrary files via an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) is...

Best of the Web
Dark Reading Radio