For months we tried to reach out to the government SaaS vendor Granicus, also known as GovDelivery, for a major security vulnerability. Nothing was responded to. Later as journalists began to ask questions, they were forced to issue a statement and fix the vulnerability.
The last post talked about the video server that Granicus sells and all of the network security flaws that happen because of that. This write-up though is going to go revisit that original breach, and look with a greater sense of detail at what was found.
In particular this post will show that the elasticsearch cluster had been previously hacked, and was in-fact part of a worldwide botnet that has previously been documented by other researchers.
Literally thousands of governments rely on Granicus software to keep citizens informed. Because we still don't know the full extent of the attack, the ongoing response to the Coronavirus crisis by the government could be widely imperiled at any time should other vulnerabilities or exploits surface.
The Proof of Malware:
The below Google Sheet contains all of the entries, or indexes, of the original exposed database. You can cross-reference some of these with the BinaryEdge screenshots above as proof. Essentially for every 1 customer = 1 entry.
Unfortunately this sheet also contains, separated out and placed at the top, 41 indexes that clearly don't follow the naming pattern that the other 1,700 do.
What are these?
They are Remote Command Execution (RCE) scripts, or malware. With names like command.php and %%2INDEX2%% they look like nothing else in the directory structure. Because also of how long it had been since the database was last patched, we know that most of the scripts (read - hacking attempts) would have worked.
It Gets Worse:
The same malware scripts shown above have actually been seen in thousands of other clusters for over a year now. The cybersecurity firm Kromtech wrote about this below:
The entire cluster, which matches hundreds and hundreds of other clusters with similar malware, is part of a botnet. Fortunately this story will take a rare mundane turn. The goal of said botnet is to swipe data from POS or Point-of-Sale register machines. This group is likely somewhat less hostile and malicious than a run-of-the-mill intelligent agency. That being said, the cluster still exists as an enormous entry point into a very broad array of precious IT assets. While the explanation is a lot more straightforward than this blog will sometimes come to, that does not decrease its vulnerability.
A Final Insult:
I end this small last post with a screenshot from the Elasticsearch documentation. You can see the big warning for anyone wanting to look at version 0.90+ of the ES reference material. Today the latest version of Elasticsearch is 7.6.1. Granicus was using 0.90.13, last updated in March of 2014.
So Granicus was using a database version not updated, patched, protected, or improved in over half-a-decade.
There were multiple unauthenticated remote code execution exploits (the highest level of bug a software can have) available for that version. Do not tolerate this behavior in leaders. Do not tolerate this behavior in people you know. Do not allow this where you work. Do not allow this to go unanswered. As the days go by and the noose of coronavirus tightens around the world, we need to make sure that companies like Granicus aren't there to pull the executioners trap door on society and destroy us all.