Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

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.
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19604
PUBLISHED: 2019-12-11
Arbitrary command execution is possible in Git before 2.20.2, 2.21.x before 2.21.1, 2.22.x before 2.22.2, 2.23.x before 2.23.1, and 2.24.x before 2.24.1 because a "git submodule update" operation can run commands found in the .gitmodules file of a malicious repository.
CVE-2019-14861
PUBLISHED: 2019-12-10
All Samba versions 4.x.x before 4.9.17, 4.10.x before 4.10.11 and 4.11.x before 4.11.3 have an issue, where the (poorly named) dnsserver RPC pipe provides administrative facilities to modify DNS records and zones. Samba, when acting as an AD DC, stores DNS records in LDAP. In AD, the default permiss...
CVE-2019-14870
PUBLISHED: 2019-12-10
All Samba versions 4.x.x before 4.9.17, 4.10.x before 4.10.11 and 4.11.x before 4.11.3 have an issue, where the S4U (MS-SFU) Kerberos delegation model includes a feature allowing for a subset of clients to be opted out of constrained delegation in any way, either S4U2Self or regular Kerberos authent...
CVE-2019-14889
PUBLISHED: 2019-12-10
A flaw was found with the libssh API function ssh_scp_new() in versions before 0.9.3 and before 0.8.8. When the libssh SCP client connects to a server, the scp command, which includes a user-provided path, is executed on the server-side. In case the library is used in a way where users can influence...
CVE-2019-1484
PUBLISHED: 2019-12-10
A remote code execution vulnerability exists when Microsoft Windows OLE fails to properly validate user input, aka 'Windows OLE Remote Code Execution Vulnerability'.