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-2013-7392
Published: 2014-07-22
Gitlist allows remote attackers to execute arbitrary commands via shell metacharacters in a file name to Source/.

CVE-2014-2385
Published: 2014-07-22
Multiple cross-site scripting (XSS) vulnerabilities in the web UI in Sophos Anti-Virus for Linux before 9.6.1 allow local users to inject arbitrary web script or HTML via the (1) newListList:ExcludeFileOnExpression, (2) newListList:ExcludeFilesystems, or (3) newListList:ExcludeMountPaths parameter t...

CVE-2014-4326
Published: 2014-07-22
Elasticsearch Logstash 1.0.14 through 1.4.x before 1.4.2 allows remote attackers to execute arbitrary commands via a crafted event in (1) zabbix.rb or (2) nagios_nsca.rb in outputs/.

CVE-2014-4511
Published: 2014-07-22
Gitlist before 0.5.0 allows remote attackers to execute arbitrary commands via shell metacharacters in the file name in the URI of a request for a (1) blame, (2) file, or (3) stats page, as demonstrated by requests to blame/master/, master/, and stats/master/.

CVE-2014-4911
Published: 2014-07-22
The ssl_decrypt_buf function in library/ssl_tls.c in PolarSSL before 1.2.11 and 1.3.x before 1.3.8 allows remote attackers to cause a denial of service (crash) via vectors related to the GCM ciphersuites, as demonstrated using the Codenomicon Defensics toolkit.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.