This is what led out of the starting gate for 2017.  A heap of MongoDB databases being pillaged by ransomware attacks. Reports were that one quarter of all those servers with MongoDBs on them (99,000 known instances) had been hit.  According to the tally being kept, the numbers rose from 2000 on January 3 to 8, 542 on January 5. By January 9, the total was over 27,000. And the numbers were rising at unprecedented rates. (image from ZDNet article Jan 9 2016)

MongoDB is wildly popular, but given my observations, it has a less than stellar track record when it comes to security. There have been some major instances cited over the past year.  In this case, the reason was not some code vulnerability but a human one. The attacks were due to an abundant lack of security: admin accounts with no password protection; outdate patches; bad attitude. These databases were pretty much left wide open on the internet. And it’s easy to get plucked when you make yourself low-hanging fruit for attackers.

Then, a few days later, there were reports that attacks had moved onto Elasticsearch clusters.  Elasticsearch is a poplar Java-based search engine used in enterprise environments. It’s good for things like log collection, data analytics, visualization.  Now those clusters were being wiped, with the count 600 as of January 13.  Again, these targets were unprotected and open to the internet. According to write ups by Catalin Cimpanu on Bleeping Computer, the attacks quickly moved onto other database servers. https://www.bleepingcomputer.com/news/security/database-ransom-attacks-hit-couchdb-and-hadoop-servers/

https://www.bleepingcomputer.com/news/security/mongodb-hijackers-move-on-to-elasticsearch-servers/

“For the past week, unknown groups of cyber-criminals have taken control of and wiped data from CouchDB and Hadoop databases, in some cases asking for a ransom fee to return the stolen files, but in some cases, destroying data just for fun.These incidents come after crooks hijacked and held data ransom from MongoDB databases since the start of the year.Security experts that have witnessed the first wave of attacks against MongoDB servers predicted that other database servers would be hit as well.A week after the initial attacks on MongoDB, ElasticSearch clusters were also hit. At the time of writing, over 34,000 MongoDB servers and 4,600 ElasticSearch clusters have been held for ransom.”

Researchers within our security community, like Victor Gevers, Niall Merrigan, @sudosev and more,  have been following and reporting on this trend.  When I asked him his thoughts, Victor said “it always gets worse before we see a (re)action”. On his Twitter feed, Victor replied to this comment, which pretty much sums things up. Niall has been actively reporting on the situation, and updating the MondoDBs to 40,000 and Elasticsearch to 5000. As well, he commented on the trend for data to not be returned citing it as”ransack ware”.

Databases were being wiped then replaced with an empty one labeled “Wrning. PWNED”. Point taken. Wiped meaning the data was not left there and encrypted. It was gone. Although if you paid the fee, you could have it restored. But is that a chance you’re willing to take? If you leave the front door open, how likely are you to have backups? In an analysis of what went wrong, referencing the ongoing battles with Shadow IT, Tony Baer made these recommendations on what needs to be done right in his piece on ZDNet http://www.zdnet.com/article/should-the-cloud-close-the-front-door-to-the-database/ :

Looking at the recent MongoDB hacks, you need to take the basic measures that might otherwise be taken for granted. And just as you would with on-premise systems, you’ll need to enforce full “AAA” (authentication, authorization, and accounting) to guard entry. Then, of course, there is the basic hardening of the instances, going down to securing and patching the operating system, ensuring only the right people access the management console, and so on. That means all communications — and we mean all — between client, administrator interface, and the cloud target must be strongly encrypted all the way down to passwords and keys.

This past week, we’ve watched the trend ingest Hadoop, Couch and Cassandra. Hadoop is a major concern, given its prominence in many major organizations, including financial institutions.  Victor reported to Bleeping Computer that the attacks on Hadoop, of which there are about 5400 known instances, looked more like vandalism as no ransom demands were being made.  They had started  January 12, with  “an unknown attacker going by the name of NODATA4U has been accessing Hadoop data stores, wiping data, and replacing all tables with an entry named “NODATA4U_SECUREYOURSHIT.” The attacks on Couch, however, were definitely monetary. A group of attackers, known as “r3l4x” may have been exporting the data or deleting it. Victor and Niall have put together spreadsheets to track the attacks. Other researchers who have joined to help are Bob Diachenko from the MacKeeper Security Research Center, Matt Bromiley from 505Forensics, and Dylan Katz from GitPrime.  Hadoop Sheet:  https://docs.google.com/spreadsheets/d/18-zmpzp87TX9oIbLwChJ3Fn0ldCGysSm-aoje_VvSSc/edit#gid=0

Couchdb Sheet: https://docs.google.com/spreadsheets/d/1iO8nINe1Ia2s40byeOj8BRiXZMpiBkKGJR5AuV7EExY/edit#gid=0

This raises more issues than just those about securing the humans. Consider it an overdue cautionary tale of a long-standing problem that was ripe for exploitation. Now – how many more of these are we aware of, festering within our realms? As everything moves to the cloud, we need to consider security procedures must be adapted to that environment. Cloud may be “somebody else’s server” but it gets complicated fast when you start taking it apart, bit by bit. There are layers of software over hypervisors, sometimes involving third party managed support. Determine where data is stored because of privacy regulations. How close are dev and prod environments, and how clean is that demarcation? Oh yes, I’ve been learning from some cloud security audits. You need to ask the right questions to get the right answers, and we like to operate from assumptions. My bottom line here is that as big data gets bigger, and the cloud surface continues to expand, we need to get more than just the basics right. Or we’ll keep growing orchards of low-hanging fruit.