In late October, database-as-a-service provider MongoHQ became the victim of a spear-phishing attack that resulted in spam issues and possible data theft for many of its clients, including social media scheduler Buffer and iPhone calendar application Sunrise. Hackers successfully exploited porous network security, obtaining credentials that happened to be shared between a personal employee account and an internal MongoHQ application.
Because MongoHQ is a DBaaS vendor, the breach had widespread implications. More specifically, the organization’s databases contained sensitive information from numerous clients and their customers in addition to MongoHQ’s own data. As such, the hack had the potential to create a domino-like effect that could have compromised assets on a considerable scale.
However, damage was mitigated by MongoHQ’s utilization of strong encryption to hash its clients’ passwords. Unlike LinkedIn, which suffered an even greater attack in 2012, MongoHQ used bcrypt instead of weaker unsalted SHA-1, and as such it was in much better position to fend off brute-force attacks.
MongoHQ was preventable with better authentication practices
Still, several companies’ databases were put at risk, and the foresight behind using bcrypt was the exception rather than the rule in regard to MongoHQ’s overall network security. Mechanisms like two-factor authentication and mandatory secure VPN login could have easily prevented this attack.
Moreover, the MongoHQ incident illustrates how certain practices that may be theoretically beneficial to operations can, under different circumstances, become liabilities to security. For example, the access controls in MongoHQ’s support application made it easy for the company to simulate troubleshooting scenarios, but in this case they granted cybercriminals unfettered access to customer email addresses and data.
Taking the necessary precautions against spear-phishing may appear obvious, but sometimes organizations only realize the value of doing so after an attack. In light of the MongoHQ breach, companies should consult the cybersecurity community and work toward making authentication both simpler and more secure, even if they do not operate in highly regulated sectors subject to PCI compliance and legislation such as HIPAA.
Password sharing, lack of VPN may have caused breach
MongoHQ detected the breach October 28, 2013. An employee accessed the company internal support console using a password shared with a compromised personal account, illustrating the dangers of password recycling.
CRN’s Robert Westervelt noted that while password management software is a key component of protecting sensitive applications, many organizations do not use it, at best regarding it as unnecessary for their industry and at worst seeing it as a massive inconvenience. Without a solution that supports regular reset of strong passwords, employees may err on the side of crafting easy-to-remember credentials that are shared across personal and business services.
MongoHQ’s support application was an ideal target for cybercriminals seeking to exploit these password practices. The portal was available over the public Internet, unprotected by VPN requirements that would have made it much tougher for hackers to locate.
Speaking to SC Magazine, JumpCloud co-founder and penetration testing expert David Campbell stated that such an approach was dubious, yet widespread. To its credit, MongoHQ has since instituted VPN to protect the application.
The application contained a distinctive feature that allowed employees to simulate the experiences of user accessing MongoHQ support pages. The lack of two-factor authentication meant that the password from the employee’s personal account was enough for hackers to gain access to this function. From there, they were able to get their hands on customer information such as email addresses.
“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,” explained MongoHQ CEO Jason McCay in a blog post. “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.”
Software startups hit by spam, data exposure after MongoHQ hack
Founded in 2011, MongoHQ hosts NoSQL databases for many high-profile customers. BloombergBusinessWeek estimated that at $1.2 billion, the company was the most valuable startup in New York City, even topping popular blogging service Tumblr.
Accordingly, the breach immediately put a number of prominent Web services at risk. Users of Buffer, a MongoHQ customer that specializes in scheduled social media sharing, noted a sharp spike in spam. Similarly, Sunrise users may have had their private iCloud data exposed in the wake of the MongoHQ breach.
However, in an explanation posted to Hacker News, Buffer CEO Joel Gascoigne stated that his company’s troubles were not entirely MongoHQ’s fault. He pointed out that Buffer had been using unencrypted access tokens, which made it much easier for attackers to hijack accounts.
Bcrypt limited the damage, but challenges remain
The dual struggles of Buffer and MongoHQ reveal that many organizations, especially startups, have neglected formulating comprehensive security strategies. These companies may feel that they do not require robust protection because they do not deal in healthcare, financial services, payments or other heavily regulated fields.
“Security is often seen as an inconvenience,” database security expert Alex Rothacker told CRN. “More common is that there is just no one in place that really understands how to set and enforce security policies.”
The MongoHQ breach illustrates that even attacks on unconventional targets – database hosting startups – can cause widespread damage and put copious amounts of data at risk. Fortunately, MongoHQ appears to have taken key steps to reduce exposure to future incidents. As Campbell noted, the company was already using bcrypt to hash passwords, which provided a starting point for more comprehensive security.
“The fact that MongoHQ appears to have been using bcrypt for customer passwords makes it exponentially more difficult for the attackers to exfiltrate the hashes and crack those passwords offline,” wrote Campbell. “Using a popular open source GPU based password cracking tool, we see that an average machine can only try 3788 possible passwords per second against bcrypt.”
McCay also revealed that the company locked all company email accounts and devices had been locked pending a reset. Security firms will also help MongoHQ implement two-factor authentication and exclusive VPN access to critical services. The attack on MongoHQ may be a cautionary tale about the perils of loose password management, but it also provides a blueprint for how to address that issue. With any luck, software companies will take these lessons to heart and secure their assets before they come into hacker’s crosshairs.