Misconfigured firewall resulted in LogBox data exposure and conflicting claims

Earlier this week, Jake Bright of TechCrunch reported that security researcher Anurag Sen had found an exposed database belonging to LogBox, a South African medical data app that allows patients to share information with their doctors more easily.

According to TechCrunch’s report, the researcher had found an exposed database containing account access tokens for “thousands of LogBox users, which if used would grant full access to users’ accounts without requiring their password, Sen said.”  Sen reportedly reached out to LogBox to responsibly disclose his findings, but they did not reply to him and would not answer any of TechCrunch’s questions. It’s unfortunate that they did not respond to Sen’s responsible disclosure, as I think they missed an opportunity to find out if there was anything else he could tell them that might help them.

DataBreaches.net reached out to both the researcher and to LogBox to inquire more about the extent and sensitivity of any patient data. Sen responded to this site’s inquiry by stating that  the tokens provided access to medical procedures of patients, prescriptions, and personal information.

LogBox provided a very different answer, however. According to their spokesperson, the vulnerability, which was in the network firewall and not the application itself, first occurred in November, 2019 and affected only a survey form introduced as part of a new feature in late 2019.

“Based on our forensic work to date, a maximum of 25,000 survey forms, predominantly relating to pilot or test data, were potentially exposed,” the spokesperson informed DataBreaches.net. “The open port enabled access to a separate and external database of traffic logs that were being used for usage-monitoring and technical support purposes.”

When asked to confirm whether any real patient data was accessible via the survey forms, the spokesperson responded:

Yes. That said, please note that the data that was lost constituted network tokens, which could theoretically have been used to access the survey form for the 3 users, and only that survey form’s contents. There is however, no evidence based on the forensic examination thus far, that the tokens were actually used to access the forms. Our view at present is accordingly that no actual patient data at all, was exposed. Rather, it was network traffic-related data.

The firm says it is committed to ensuring that this incident, or something similar, does not recur, writing that they believe that the added security-related measures they have already taken, coupled with support from external specialists, should ensure that LogBox is safe to use.

Quite aside from any other consideration, LogBox has proven to be a remarkably potent tool in improving clinical case collaboration, where multiple medical specialists are involved, treating gravely ill patients. We are committed to ensuring that it is not derailed by this incident, and the unfortunate manner in which it was reported by TechCrunch.

That LogBox has developed a good reputation seems undeniable, and the site notes that it is “Approved by the Colleges of Medicine South Africa.” But was TechCrunch’s reporting “unfortunate” in the sense of “inaccurate?”  And is LogBox’s explanation consistent with the researcher’s findings?

When contacted for a response to LogBox’s claims, TechCrunch stated it is standing by its reporting.

As part of this site’s attempt to resolve the conflicting claims by Sen and LogBox, DataBreaches.net obtained more information. To cut to the chase: that information provides support for TechCrunch’s reporting. More importantly, it is  inconsistent with LogBox’s description of what was accessible. None of the limited data obtained by DataBreaches.net has anything to do with any survey forms. To the contrary, the data appears to be from the startup’s Academic platform and perhaps one other platform.

In addition to that conflicting data, DataBreaches.net also obtained evidence of a ransom note that was allegedly left on LogBox’s server.  This particular ransom note had been seen on a number of other servers back in May – June, 2019, with earlier detections of “howtogetmydataback” noted in the wild in September, 2018. That said, it is not clear when this alleged attack on LogBox occurred, or why the ransom note would still be  on their server.

All told, it is important to remember that what happened here demonstrated a vulnerability and not an actual data breach. And we all know how many misconfigured databases we’ve seen in the past 3+ years. But it is unfortunate that the startup did not take advantage of a whitehat researcher who tried to responsibly share with them what he had found. I would encourage LogBox to reach out to him to see if he would still be willing to share his findings and recommendations with them so that they can be confident that they have fully addressed any vulnerabilities he may have found.

About the author: Dissent

Comments are closed.