Greetings from the Couch
Sep 10 · 4 min read

Update — within days of writing this article, an almost identical breach occurred in the United Kingdom.

On July 1st this year,, a US based cyber-security company detected and reported a publicly accessible MongoDB database with the name “neoclinical”.

Neoclinical happens to be an Australian based company that helps match patients with active clinical trials through collection of personal and medical data.

According to reports, Upguard were able to breach the MongoDB database through hacking a user account, a simple username and password combination. This formed a single point of failure which exposed 37,000 patient records, together with entities responsible for connecting patients with trials, questions used to match patients, and user accounts of the medical organizations administering the trials.

Luckily for Neoclinical, Upguard did their best to help; the security researcher contacted the company through their official telephone numbers and email addresses, monitored the situation then escalated to Amazon Web Services Security when the database remained online. AWS took down the database within 24 hours. However, what’s not clear, and may never be, is how long the database was publicly accessible, and whether it had already been hacked.

What went wrong?

There’s two main questions to answer;

First, why was the database exposed to the internet, even if it was password protected as Neoclinical’s spokesperson stated?

There are two possibilities, either a configuration issue, where the database was mistakenly made publicly accessible, or perhaps this was by design, so different parties could access the data via web forms, direct access or via apps.

Nonetheless, naming the database “neoclinical” automatically linked it to the company, which undoubtedly made it a more tempting target.

Second, the user account breached by Upguard had access to the entire database, data and user accounts. This was a deliberately created user account, because unlike other databases, MongoDB has no default SuperUser account. Regardless, there was such an account at the time of the breach. With this level of access, Upguard could have created multiple login accounts then started exfiltrating data. Administrator accounts are a necessary evil, but there are ways to restrict access to both data and administrative functions which should be used. The problem lies in those situations where they are not.

How could this have been avoided?

The Neoclinical breach proves one thing categorically: making a database publicly visible is a mistake. If it’s on the internet, it’s a target. This scenario is the equivalent to putting the British Crown Jewels in a glass box out front of Buckingham Palace guarded by a single, if heavily armed, Queen’s Guard Infantryman. If you can get past the guard, the jewels are yours for the taking.

Another reason for making a database publicly accessible is to act as a honeypot for hackers. The issue lies in the unintentional exposure.

So, securing the database is the first order of business. This can be done through database permissions, perimeter security, firewalls, and suchlike that protect the database. Then you can add VPNs (Virtual Private Networks) or SSH (Secure SHell) to secure the network.

However, these are are no guarantee of security. For example, Equifax was breached due to unpatched hardware. So the next level of protection should include a Zero-Trust approach to database access.

“Zero Trust” begins with the assumption that your network has already been breached; the barbarians aren’t at the gates, they’re on both sides of them! So with a Zero Trust approach, nothing is trusted and everything is verified in every interaction. Neoclinical’s MongoDB database is a case in point; it was on the internet, secured with a weak password!

So how do you determine who should have access? In Neoclinical’s case, these users can be broken down into four categories:

  • An administrator account to configure and administer the database itself, but who is unlikely to require access to the data.
  • The patients who fill out the web forms, who add their data, and according to legislation such as GDPR and Australia’s on Privacy laws, must be owners of the data, have free access to it, and determine who or what has access.
  • The third parties performing analyses on patient data and trial requirements, but not patient identification.
  • The trial administrators themselves who contact or are contacted by successful patients.

But what does this mean for my organization?

Simply put, zero-trust principles mean you’ve got to do the following:

  • Secure all direct database credentials (such as the logins to the database the Upguard researcher used). This means you must NEVER hand out database or system logins willy-nilly.
  • Manage all secure database connections, using VPNs or network security.
  • Allow creation of user accounts, including additional authentication methods such as two-factor and push authentication.
  • Control user account access to data; users see only what they’re authorized to view, edit or delete.
  • Allow connection only for authorized users.
  • Notify and log connection attempts for audit and administration purposes.


Disorderly Instruct

Sharing knowledge and making things clear

Greetings from the Couch

Written by

Really not a neural network enhanced instabot from the nastiest burrows of the darknet. (also do chai reviews on @melbournechai )

Disorderly Instruct

Sharing knowledge and making things clear

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade