Since the summer of 2019, this site has occasionally reported on findings by WizCase researchers, such as our report in October on multiple entities that they had discovered leaking medical or health data.
Today, WizCase reported on three more leaks that they discovered leaking patient data. They shared their findings exclusively with DataBreaches.net.
The first of these is HX Wellness Private Limited’s Aermed Online Pharmacy App. WizCase found 4 GB of data including approximately 230,000 records were exposed in a MongoDB server and Amazon AWS S3 bucket. The leak involves both both patient and doctor information.
According to WizCase, the exposed server was hosted in Singapore.
The data were locked down on December 12 in response to WizCase’s notification of December 8, but the firm did not respond to the researchers at all, even after the researchers sent an additional notification that files in the AWS S3 bucket are still exposed and downloadable if anyone had copied the directory of filenames while it was exposed. As proof, WizCase provided DataBreaches.net with a direct link to an exposed file on the bucket. Since that time, WizCase also contacted Amazon about the bucket, and Amazon responded that it would notify its customer. DataBreaches.net also reached out to HX Wellness via email to notify them and obtain additional details, but has gotten no reply by publication time.
So what data was available in the exposed backups? According to WizCase researchers’ analysis, the leak exposed sensitive patient details including full names, age, location, email, gender, medical records, order information, and prescription information. Patients’ medical scans could also be accessed without authentication from the exposed Amazon bucket. More specifically, the researchers found:
- ±40K entries of patients (identifiable with email) with
additional medical info and more personal details such as
age and more; - +32K entries with prescription medication data;
- ±220 entries about patients and doctors;
- ±78K entries about order information from the app;
- ±64K entries with user browser info and IP address;
- ± 15K of user data entries (names, location, phone number); and
- ±1.7K entries with patients’ full names and medical info.
DataBreaches.net reviewed a sample of the exposed data that WizCase provided. Not all of it appeared to be real data, but there appeared to be enough real data to be concerned.
The second leak WizCase discovered involved Mobile Health Pte’s MaNaDr Mobile Health, a concierge medical services app that lets patients consult with doctors, book appointments and home visits, and get tests results directly on their smartphones. The app’s patients seem to be primarily in Singapore, but the researchers also found users in Australia.
A public-facing elasticsearch server and misconfigured Amazon AWS S3 buckets contained what appeared to be approximately 842,000 records with patient data.
According to the researchers, they found the following, although some of the entries appeared clearly invalid/fake:
- ±4.6K entries of Transactions made using the app that included:
- patient ID which can be correlated to the full details;
- amount paid;
- date;
- doctor’s name; and
- appointment title.
- ±27K entries of Appointments with:
- medical information such as abnormal fields from lab test;
- Patient ID;
- Doctor’s name;
- Lab name; and
- Clinic name.
- ±813K entries that include patients’:
- full names (included under the last name field);
- NRIC (Singapore’s ID number);
- age & date of birth;
- phone number;
- patient ID (can be correlated with other parts of the DB);
- nationality, race, and more.
For some entries, some fields were occasionally missing (e.g. email).
WizCase contacted MaNaDR on February 1 by email, and the data were locked down shortly thereafter. On February 2, the firm replied to the notification, saying that they had closed the leak. Of note, they claimed that it was a server with mostly test data. When the researchers attempted to validate the entries, however, they found that there appeared to be legitimate data. While one of the Amazon buckets seemed to be for test purposes, not all of the data involved in this leak appeared to be test or demo data.
The third leak WizCase shared with this site involved Zaldivar Institute in Argentina, an ophthalmological treatment center.
In this incident, the researchers found a 72 MB elasticsearch server with 8,600 exposed employee and patient records. There were actually two servers that held more or less identical information: confidential patient information, including full names, Argentinian ID and passport numbers, emails, phone numbers, general details of professions, birth dates, nationality, and addresses.
You can read WizCase’s report on these three leaks and the potential risks they pose here.
Update on their October report:
Back in October, WizCase and DataBreaches.net reported that a pharmacy software firm appeared to have an open Elasticsearch server and GoogleAPI bucket. The former contained about 800 records, while the exposed bucket had thousands of images of prescriptions and medicine bottles. VScript, who WizCase believed to be the owner, had not responded to WizCase’s attempt to notify them. Nor did VScript respond to a phone call from this site. The bucket remained unsecured even after Google contacted their customer.
To their great credit, WizCase did not give up even after their report was published. In December, finding the data still unsecured, they contacted US CERT. They got no response, but inform this site that now both the leak and the open GoogleAPIs bucket seem to be finally closed. And since whoever was responsible for that leak never thanked them for their efforts to secure patient data, this site will say a huge thank you to WizCase for caring about patient data and donating so much of their time to getting those data locked down.
But let me use this opportunity to remind entities who do not respond to notifications: you are foolishly missing an opportunity not only to reinforce responsible disclosure, but you are missing an opportunity to find out what data of yours may be in the researchers’ (or journalists’) hands. Now maybe you don’t intend to notify anyone about the incident, but sticking your head in the sand in response to an incident and/or trying to censor reporting by researchers or journalists is just… not good governance and stewardship.