Last week, the NoSQL database host MongoHQ suffered a breach which exposed customer files, email addresses and password data to the attackers. The ripples from that breach are still being felt, as users of the Sunrise calendar app on the iPhone found out this morning.
Luckily that password data was not only encrypted, but hashed using bcrypt. As security expert Paul Ducklin from Sophos explains: "bcrypt is a so-called keystretching function that ramps up the time it takes for a supplied password to be checked against its stored hash, by requiring various parts of the hash calculation to be repeated thousands or even tens of thousands of times, rather than just once. That means it takes thousands or tens of thousands of times longer to check each password - not much of an inconvenience when you are validating passwords one-by-one when customers login, but a giant roadblock when you are a crook wanting to try a dictionary attack using millions of likely passwords."
Jason McCay, MongoHQ Founder and CEO, has gone on the record to apologise which is good, but what's better is that he has also explained the processes being put in place to ensure the same thing cannot happen again. "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" McCay says "As one of the founders of this company and a part of this great team, I hoped to never have to send this notice. The safety of your data is our top priority. We are taking all appropriate steps to mitigate this risk and protect you."
The MongoHQ security notice states:
On October 28, our operations team detected unauthorized access to an internal, employee-facing support application.
We immediately responded to this event, by shutting down our employee support applications and beginning an investigation which quickly isolated the improperly secured account. We have determined that the unauthorized access was enabled by a credential that had been shared with a compromised personal account.
No internal application was made available to our team before a team-wide credential reset and audit.
Users of our support application have access to account information, including lists of databases, email addresses, and bcrypt-hashed user credentials.
Our support tool includes an "impersonate" feature that enables MongoHQ employees to access our primary web UI as if they were a logged in customer, for use in troubleshooting customer problems. This feature was used with a small number of customer web UI accounts. Our primary web UI allows customers to browse data and manage their databases. We are contacting affected customers directly.
We have additionally determined that an unauthorized user to our support system would have had some access to our account database, which includes connection info for customer MongoDB instances.
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. We are contacting affected customers directly. If you have not heard from us individually, there is no evidence that your DB was accessed by an unauthorized user.
MongoHQ has been using a third-party to validate that it has fully functioning and enforced two-factor authentication and that access to all applications is provided solely through VPN with a system of thoroughly tested and graduated permissions that only allows the minimum needed privileges to support personnel based on role. While this work continues, MongoHQ has mitigated internal application risk by disabling many applications entirely and has enabled two-factor authentication for email and back-office applications. Furthermore, every internal database that is operated by MongoHQ has been re-credentialed and the operating environment rigorously audited. Oh, and the Amazon Web Services credentials stored for clients invalidated to prevent malicious use by the attackers.
All of which is not only good from the perspective that it is being done, but good that MongoHQ is taking the full disclosure route and letting us know that it is being done. Such honesty in the face of a major breach such as this helps to restore trust in what could so easily otherwise become a damaged brand. Of course, it goes without saying that there would be no damage to repair if the user who had the same password for his work account as one of his personal accounts (which got hacked) had a better understanding of basic security measures.
Jason McCay isn't the only CEO apologising as a result of the MongoHQ hack. Pierre Valade, CEO at Sunrise (a calendar app) has also been saying sorry to his users. This arrived in my inbox (I briefly tried the app before deciding it wasn't for me) this morning, rather longer after the original breach event than I find acceptable truth be told:
We have been informed that our database provider (MongoHQ) has experienced a security breach. In handling security incidents, our priorities are to make sure your data is safe, eliminate the control failures that allowed the breach to occur, and to report the incident accurately to our customers.
Here is what it means for you:
Your Google, Facebook and Twitter data are safe. We've refreshed the identification key that allows our servers to communicate with your connected accounts, which means any data that could have been taken by a malicious party is useless before or after the incident.
Your LinkedIn, Foursquare and Producteev data are safe. You’ll just have to reconnect those services to Sunrise, as they don’t offer the same security control as Google, Facebook or Twitter.
If you chose the “Email” option to sign up to Sunrise: your Sunrise email and password are also safe. We encrypt them in our database using the industry standard algorithm (bcrypt).
If you connected an iCloud calendar to Sunrise, even though we don’t store any credentials, the security breach may have put some of your calendar data at risk. As a precautionary measure, we recommend that you change your iCloud password and reconnect it to Sunrise: simply click here and then click on “Reset your password” to do it.
As one of the many precautionary measures we are taking, we will be logging every Sunrise user out of the app. Simply log back in using the “I'm Already a Sunrise User” button and choosing one of the options that you had previously connected to your account.
Just to be clear, none of the data affected by this incident has any access to your credit card or banking information.If you run into any trouble or if you have any questions, please email us at support@sunrise.am. We are here to help.
We are incredibly sorry that this happened. Your security is very important to us, and once we were aware of the issue we took immediate steps to protect you and maintain your trust.
The problem for end users being that they just do not know what apps and services were making use of the MongoHQ cloud service, and whether the app they are using has been impacted by this breach or not, unless and until that developer tells them. I have the feeling that ripples from the MongoHQ hack will be felt for some time yet...
