Barely a day goes by anymore without another report of sensitive data being left accessible to anyone on Elasticsearch servers or MongoDB
databases that have not been properly configured.
Today is no different.
As ZDNet reports
, researchers have discovered several exposed servers that belong to Chinese recruitment firms.
Security experts Devin Stokes
, Sanyam Jain
and Bob Diachenko
have played a key role in uncovering many of these exposed databases, which typically contain contact details of executives hunting for new jobs alongside their current salary, career and education history, salary as well as information about their skill set and the training that they have received.
Writing for ZDNet
, Catalin Cimpanu calculates that the researchers' various breach discoveries amount to a staggering 590 million resumes that have leaked from Chinese companies in just the last three months.
Some may think that to have half a billion resumes accessible via the public internet isn't that much of a problem. After all, LinkedIn claims to have 590 million users itself, many of whom will have shared details of their work and education history.
The difference is, of course, that resumes shared with recruitment agencies and head hunters contain much more personal information than that which you're likely to share with a site like LinkedIn. For instance, when you feel like you are only sharing your details with a human resources agency, you are much more likely to submit details such as your personal home address, your precise date of birth, your salary requirements, and so forth.
And all of this additional information could be potentially abused by fraudsters and online criminals.
What's frustrating is that it is not rocket science to harden the security of an Elasticsearch server or MongDB database to prevent unauthorized access.
For instance, there are security measures built into MongoDB; it’s just that far too many reckless or ignorant administrators don't make use of them. They choose instead to leave sensitive data accessible to the entire internet without having so much as an admin password in place.
It may be a crazy thing to do, but sadly, it's not unusual.
The maintainers of the open source database software have not washed their hands of responsibility entirely and have called upon users to read the MongoDB security checklist
, read security-related resources
and even configure alert notifications
if an instance is found to be exposed to the public internet.
Meanwhile, security features on Elasticsearch instances are disabled by default, making it possible for administrators to effectively ignore the essential requirement to implement a proper defense before rolling their live system out.
So, the resources are out there to properly secure your systems if you really want to.
But the other area that definitely needs to be looked at is how companies respond when notified of a data breach.
White-hat researchers who uncover these data breaches typically invest time and effort into trying to contact the organizations who have left the sensitive information unsecured on the public internet. However, that doesn't mean that every organization responds by rapidly shutting down a leaky server or offers any response at all.
On some occasions, the researchers had to resort to contacting the China National Computer Emergency Response Team (CNCERT), as they were finding it difficult to get any meaningful response from the recruitment companies themselves.
Still other databases, meanwhile, remain online, sometimes because it has simply proven impossible to determine who owns the poorly-configured server that is leaking personal information.
Yes, it must be a frustrating job for the researchers who will typically receive no financial reward for their efforts and whose only satisfaction may be in seeing at least some of the leaky servers shut down. I feel sorry most of all, however, for the innocent job hunters who put their trust in a recruitment company to find them a new job and never realized that their personal information would end up littered across the internet.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.