Update: 28/02/2017 Children using the IoT-enabled smart toy CloudPets, which allows children to record and share audio messages online, could have had their data stolen due to the company running its production code in a public and unsecured MongoDB database.
CloudPets are teddy bears that featuring microphones and speakers and can be accessed via an accompanying smartphone or tablet app on iOS or Android.
Security researcher Troy Hunt discovered that CloudPets’ data was located in a public MongoDM database with no authentication and could be found on IoT search engine Shodan.
One of the anonymous researchers who originally identified the breach contacted CloudPets on multiple occasions – starting 31 December – but the company didn’t return emails or notify customers of the possible breach. The business was warned that the open database put more than 820,000 users at risk of exposure.
Hunt contacted Motherboard journalist Lorenzo Frenceschi-Bicchierai, who had been separately alerted to the CloudPets breach.
Hunt then examined the traffic between the mobile application and the server and found that his profile picture was stored without security on Amazon S3, and could be downloaded provided the file path was known.
Profiles contained other personal details, including names of children and authorised family members. Worse, voice recordings were available for download in the same way – all that needed to be known was the file path, which can be found in the app.
“The services sitting on top of the exposed database are able to point to the precise location of the profile pictures and voice recordings of children,” Hunt writes.
Worse still, CloudPets made no minimum password requirements for users when registering – and while these were stored with the bcrypt hash, Hunt was able to crack a large number of accounts by using common passwords like “qwerty”, “password”, and “123456”. In a CloudPets video demonstrating how to register the account, the given example password was simply “qwe”.
According to Hunt, all of this together meant that anyone could gain access to the database, crack passwords, log in to accounts, and download voice recordings.
Spiral Toys CEO Mark Myers denied that any voice recordings were stolen, despite Hunt having demonstrated exactly how it could be done.
“The headlines that say 2 million messages were leaked on the internet are completely false,” he said. “We looked at it and thought it was a very minimal issue.”
Whether or not voice data was stolen, there appears to be evidence of ransomware attacks, similar to the wave of MongoDB attacks detailed below. As Lieberman Software’s Jonathan Sander noted to ComputerworldUK when the attacks began, the risk was probably “low” to most companies – but CloudPets seems to have been one of the exceptions.
The incident raises further questions about the security of IoT-enabled devices, with the danger that an irresponsible oversight can place potentially millions of users at risk.
Update: Cybercriminals are now targeting Java-based search engine ElasticSearch in a similar way to the recent string of MongoDB ransom attacks.
The attacks were first discovered by security researcher Niall Merrigan, and the criminals appear to be going after ElasticSearch instances that are connected to the internet, either without password protection or with easy to guess passwords.
A group called P1l4tos is believed to be behind the attacks. Merrigan found that over 600 hosts have been hit by the ransomware so far, and a search on Shodan turns up tens of thousands of ElasticSearch servers that are available online.
Like the MongoDB attacks, cybercriminals went after Elastic users who had not secured their data stores. As one user points out on the Elastic forums, in their instance the open cluster was used exclusively for test environments – much like the open MongoDB databases will have been. But there could be some organisations storing critical data on Elastic.
Security researcher and blogger Itamar Syn-Hershko has put together this post with advice on securing ElasticSearch. In it, he stresses the importance of hiding clusters deep in private networks and accessible only to your applications, along with disabling unused features and switching from default ports.
Alienvault's Javvad Malik says the attack "highlights the disconnect between many developers from good security practices."
“Like MongoDB, the ElasticSearch attacks are not so much about the technologies themselves, but in the way people have implemented them using either default configurations or weak passwords," Malik says.
Ransomware groups have now launched attacks on more than 30,000 MongoDB databases, demanding just under £200 in Bitcoin to regain access.
The first instances were uncovered by GDI Foundation's Victor Gevers in late December, but now multiple groups are thought to be involved.
Reports so far say that the attacker erases a database and demands the ransom before restoring it – so far 16 victims are believed to have paid up. Generally the advice with ransomware is not to pay unless absolutely necessary, as it's possible that even after coughing up the cash there's no guarantee that files will be restored.
Infosec researcher Victor Gevers found an open MongoDB server in December last year, without password protection. Its text read:
"_id" : ObjectId("5859a0370b8e49f123fcc7da"),
"mail" : "[email protected]",
"note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"
The attacks were by someone going by the name of Harak1r1 who demanded a relatively small Bitcoin payment to swap the original database back in – but there's now a growing list of copycat attacks from different aliases, recorded in this Google Doc.
As security researcher Tim Kadlec notes, versions of MongoDB running before 2.6.0 accept remote connections without authentication and with a default port of 27017, making it easy to sniff out vulnerable connections using search engines such as ZoomEye.
There's a long checklist of security configuration advice plus tips on access control, data protection and encryption at the MongoDB website, so the attacks are not reflective of security flaws in MongoDB per se, but rather the decision to allow unauthenticated remote connections by default. It could also be lax security culture in the testing environments where MongoDB is often used - and where many platforms are run in their out-of-the-box flavours.
"It appears the victims of the MongoDB ransomware were running default configuration, which allowed attackers to gain access," says Javvad Malik, security advocate at AlienVault. "If businesses are running MongoDB, they should ensure it is not running in default mode and that the security features are taken care of."
There are plenty of high-profile businesses that use MongoDB, so it is a little alarming that so many of these databases were running on default settings with open ports – something noted by the founder of internet of things search engine Shodan in December 2015. A search on Shodan for MongoDB databases shows that 99,000 databases could be at risk of attack.
In a blog post, director of product security for MongoDB Andreas Nilsson writes that the attacks are "preventable" with the "extensive security protections" that are built into the product.
"You need to use these features correctly, and our security documentation will help you do so," Nilsson writes. Nilsson goes on to list some suggested steps users can take to check if their data has been compromised.
While it's recommended that MongoDB users secure their databases, according to Jonathan Sander, VP of product strategy at security company Lieberman Software, the actual risk behind these attacks is likely to be relatively low.
"The real risk of this MongoDB ransomware is probably pretty small," Sander says. "If you look at the way people are using MongoDB right now, a great deal of it is in experimental phases – so there might actually be valuable data sitting in the MongoDB, but it won't be the only copy of the data."
"At least in enterprises that would have data anyone might pay for, what that tells me is that this ransomware is not going to get paid off – the whole point of the ransomware is they have leverage over you and you need it back," he explains. "With MondoDB, it's not likely you need that data back, at least not from that database. It's probably somewhere else. You can probably delete the entire virtual machine MongoDB sits on and forgets about it, which is annoying but not worth paying for."
Sander does add that there will be exceptions. He notes that the mode of attack is puzzling from a business-case point of view – adding that the "better attack" might be to gain access to the "weak, soft underbelly in these labs, sitting there with all this information where the information might have some value."
The value in obtaining this information wouldn't be in holding it to ransom, but to enrich the "big data sheet of stolen credentials and stolen information – that would be the thing I'd have thought they would attack."
"They are not siphoning off the information, but it is a standard ransomware attack where they don't steal the information, they just lock it up where it lives," Sander says.
It's unlikely that the attacks are a red herring to gain access to data, agrees Jason Garbis, VP of products for Cryptzone.
"If an attacker just wanted to access the data there'd be no reason for them to advertise the fact that it had been stolen," he tells Computerworld UK. "These criminals aren't threatening to release the data – this looks like a disorganised group of attackers simply looking to extract some ransom money."
"In fact, according to the security researchers tracking this, the few people who have paid the ransom have not had their data back," Garbis adds. "On top of this, we're seeing multiple attackers step on each other's ransom notes. This entire situation is a dog's breakfast."