MEDantex, a Kansas-based company that provides medical transcription services for hospitals, clinics and private physicians, took down its customer Web portal last week after being notified by KrebsOnSecurity that it was leaking sensitive patient medical records — apparently for thousands of physicians.
On Friday, KrebsOnSecurity learned that the portion of MEDantex’s site which was supposed to be a password-protected portal physicians could use to upload audio-recorded notes about their patients was instead completely open to the Internet.
What’s more, numerous online tools intended for use by MEDantex employees were exposed to anyone with a Web browser, including pages that allowed visitors to add or delete users, and to search for patient records by physician or patient name. No authentication was required to access any of these pages.
This exposed administrative page from MEDantex’s site granted anyone complete access to physician files, as well as the ability to add and delete authorized users.
Several MEDantex portal pages left exposed to the Web suggest that the company recently was the victim of WhiteRose, a strain of ransomware that encrypts a victim’s files unless and until a ransom demand is paid — usually in the form of some virtual currency such as bitcoin.
Contacted by KrebsOnSecurity, MEDantex founder and chief executive Sreeram Pydah confirmed that the Wichita, Kansas based transcription firm recently rebuilt its online servers after suffering a ransomware infestation. Pydah said the MEDantex portal was taken down for nearly two weeks, and that it appears the glitch exposing patient records to the Web was somehow incorporated into that rebuild.
“There was some ransomware injection [into the site], and we rebuilt it,” Pydah said, just minutes before disabling the portal (which remains down as of this publication). “I don’t know how they left the documents in the open like that. We’re going to take the site down and try to figure out how this happened.”
It’s unclear exactly how many patient records were left exposed on MEDantex’s site. But one of the main exposed directories was named “/documents/userdoc,” and it included more than 2,300 physicians listed alphabetically by first initial and last name. Drilling down into each of these directories revealed a varying number of patient records — displayed and downloadable as Microsoft Word documents and/or raw audio files.
Although many of the exposed documents appear to be quite recent, some of the records dated as far back as 2007. It’s also unclear how long the data was accessible, but this Google cache of the MEDantex physician portal seems to indicate it was wide open on April 10, 2018.
Among the clients listed on MEDantex’s site include New York University Medical Center; San Francisco Multi-Specialty Medical Group; Jackson Hospital in Montgomery Ala.; Allen County Hospital in Iola, Kan; Green Clinic Surgical Hospital in Ruston, La.; Trillium Specialty Hospital in Mesa and Sun City, Ariz.; Cooper University Hospital in Camden, N.J.; Sunrise Medical Group in Miami; the Wichita Clinic in Wichita, Kan.; the Kansas Spine Center; the Kansas Orthopedic Center; and Foundation Surgical Hospitals nationwide. MEDantex’s site states these are just some of the healthcare organizations partnering with the company for transcription services.
Unfortunately, the incident at MEDantex is far from an anomaly. A study of data breaches released this month by Verizon Enterprise found that nearly a quarter of all breaches documented by the company in 2017 involved healthcare organizations.
Verizon says ransomware attacks account for 85 percent of all malware in healthcare breaches last year, and that healthcare is the only industry in which the threat from the inside is greater than that from outside.
“Human error is a major contributor to those stats,” the report concluded.
Source: Verizon Business 2018 Data Breach Investigations Report.
According to a story at BleepingComputer, a security news and help forum that specializes in covering ransomware outbreaks, WhiteRose was first spotted about a month ago. BleepingComputer founder Lawrence Abrams says it’s not clear how this ransomware is being distributed, but that reports indicate it is being manually installed by hacking into Remote Desktop services.
Fortunately for WhiteRose victims, this particular strain of ransomware is decryptable without the need to pay the ransom.
“The good news is this ransomware appears to be decryptable by Michael Gillespie,” Abrams wrote. “So if you become infected with WhiteRose, do not pay the ransom, and instead post a request for help in our WhiteRose Support & Help topic.”
Ransomware victims may also be able to find assistance in unlocking data without paying from nomoreransom.org.
KrebsOnSecurity would like to thank India-based cybersecurity startup Banbreach for the heads up about this incident.
Reminds me of the FTC’s consent order with GMR Transcription, the 50th data security case the Commission has settled since undertaking its data security program in 2002.
https://www.ftc.gov/news-events/press-releases/2014/01/provider-medical-transcript-services-settles-ftc-charges-it
Apparently companies like MEDantex are considered “business associates” and are not directly covered by HIPAA as they are not a “covered entity” and only indirectly subject to HIPAA requirements via contract agreements.
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html
Also, encryption is not a requirement under HIPAA even for covered entities.
https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-use-of-encryption-mandatory-in-the-security-rule/index.html
Time for a new contract and MEDantex and others to get their act together, if only to protect themselves from class-action lawsuits.
Actually, business associates are directly covered by HIPAA as of Sept. 2013. The HIPAA Breach Notification Rule, 45 CFR §§ 164.400-414, requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information.
Additionally, encryption is now required – §164.312(a)(2)(iv): Implement a mechanism to encrypt and decrypt electronic protected health information.
Thanks for the update Lori.
I found the 2013 FR notice covering the updated HIPAA security/privacy/notification requirements that states:
Compliance date: Covered entities
and business associates must comply
with the applicable requirements of this
final rule by September 23, 2013.
https://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf#page=130
HTML version here:
https://www.federalregister.gov/documents/2013/01/25/2013-01073/modifications-to-the-hipaa-privacy-security-enforcement-and-breach-notification-rules-under-the
Lori, correct me if I’m wrong, but I believe the encryption standard applies to a CMS CEHR incentive program. At the moment, HIPAA is broad (too broad) in just insisting that medical data be kept safe. I’m sure mandatory encryption is around the corner, though (and who would ever operate without it?).
Encryption does nothing to solve this problem, proper authorization does. Encryption is only a tool that people assume forces companies to get the authorization part (access to the keys) correct. That assumption is not always true.
The encryption standard is part of the HIPAA Security Rule under the 2013 Final Omnibus. However, it is “Addressable” rather than “Required”. That doesn’t mean you don’t need to do it, but it means that the covered entity or business associate must assess whether it is “a reasonable and appropriate safeguard” in their environment. If they decide it is not reasonable and appropriate, they must document why, and implement an “equivalent alternative measure if reasonable and appropriate”. I am not sure what OCR would consider to be an equivalent alternative measure for encryption and what would be a valid reason for deeming it not reasonable and appropriate if you were audited or investigated.
In 2013, in particular, a business case could be made by Dr. Small Rural Clinic that putting his files in a firesafe was the best he could do, given his resources. If someone happened to blow up the safe and gain access to the records, I doubt HHS would have said he didn’t make a reasonable effort to protect patient data.
If HHS mandates technical controls for HIPAA compliance, our hospitals will go stone-cold broke. They’re running some of the most outdated software on the planet and have little to no onsite tech support. I believe this is why, to this point, they have not mandated encryption.
Not true. §164.312(a)(2)(iv) lists encryption as an “addressable” control. Notwithstanding the challenges in adequately “addressing” that control where encryption is a good fit, the option is still there to manage the associated risk via other means.
Merely mandating encryption does not make data safe. Encryption only protects data in physical storage, or from prying eyes in transit (from server to client). For simplicity sake I’m ignoring algorithm weaknesses.
Encryption does not solve the “authorized user” problem by itself. Weak passwords, compromised software keys, and weak authentication are the number one end run around encryption. Number one because humans are reliably lazy with both implementation as this case, and managing passwords. The top five passwords found in the wild are easy: password, 123456, 1234678, 1234, and qwerty. Right behind that are variations on those themes, the user’s name, phone number, DOB, etc. You can find these passwords at work as well as for personal accounts. On top of that most people are inclined to write down PINs and passwords. Attackers can ignore encryption if the end points are not secure. Thanks to human frailties and laziness, they often aren’t.
Sometimes you come across sites like this one apparently does, that doesn’t even bother to block server file listings… you just shake your head and wonder who the numb nuts was that set that up and why no one in their IT dept even noticed. Securing internal file listings is Rule 1 of any server deployment.
Securing encryption keys with passwords is like putting scotch tape on your lock box.
Encryption keys should be protected with something much, much stronger otherwise what is the point? HSMs are one way to protect keys, at PreVeil we store keys only on trusted devices and use true end to end encryption so that any remote attacker only gets encrypted data whether they steal it at rest or in transit. They would have to physically compromise the end point with the key which reduces the attack surface immensely.
Will they be required to notify every physician that their data was compromised?
The requirement for notifications of breaches is covered here:
https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
Health Care IT is actually a bright spot in the regulation of information security. CMS (Center for Medicare and Medicaid Services) is a US federal agency. Quid mentioned the reporting procedure.
They also have a hall-of-shame web portal where breaches affecting over 500 individuals are, eventually, made public.
https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
(And yes, “associated business entities” are covered by HIPAA. The place I work is such an entity. And, no, we’ve never made it into the hall of shame.)
I don’t know about anyone else here, but I am getting “breach fatigue “
Wonder if they hired the former Equifax security officer.
“Our security and HIPAA compliance team is made up of department managers and headed by a security officer that continually monitors your data.”
http://medantex.com/Why-MEDantex/Security.html
“Wonder if they hired the former Equifax security officer.”
My thoughts exactly.
Let the lawsuits begin!
HIPPA breaches aren’t actionable civil liabilities by citizens. They can only be fined by the government. To put it briefly, the HIPPA law doesn’t permit the Average Joe to sue under its rules. Other laws may apply, but not HIPPA.
Just wait until GDPR kicks in, these slackers will have to fasten their seatbelts, and it will be a bumpy ride.
You’re joking right? GDPR is a European Union law that goes into effect next month. It has nothing to do with anything inside the borders of the US. It’s irrelevant outside the borders of the EU states regardless of what the EU lawmakers think. The only companies that have to care are those that have physical presence in the European Union and wish to directly engage with EU citizens. Otherwise, everyone else can and will ignore it.
This is so not true. It is already having a huge impact on companies outside of Europe, because most large companies have customers in the EU. And I believe GDPR will have a detrimental effect on security worldwide.
https://krebsonsecurity.com/2018/03/who-is-afraid-of-more-spams-and-scams/
https://krebsonsecurity.com/2018/02/new-eu-privacy-law-may-weaken-security/
Instead of ignoring; identifying & documenting data-flows, to be able to demonstrate either lack of EU data or that you have deidentified EU data may be a better approach.
Physical presence in EU puts companies under jurisdiction of the law by “establishment”. But the scope of GDPR extends farther geographically than NYDFS and HIPAA combined because of GDPR’s new expanded definition of “personal data” and who may be considered a “processor” of such data regardless of location or industry (not limited to financial services or health).
Many non-EU companies are not ignoring, but instead using Record of Processing Activities (RoPA), Article 30 of GDPR, to help avoid being an easy target for regulators, by establishing awareness of who, where and how their data is processed, in a RoPA.
medical records? who needs your medical records??
btw..i dont think you can make any money out of someone ś medical records? will you?
my opinion is this ,if you cant make cash real cash then its pointless to make any efforts in anything.
i m not sure what can be done with medical records???
Medical records are very valuable. People without coverage can use them to impersonate you, receive care, and leave you with the bills. Additionally, full medical records make identity theft rather easy.
https://www.consumer.ftc.gov/articles/0171-medical-identity-theft
https://www.forbes.com/sites/forbestechcouncil/2017/12/15/the-real-threat-of-identity-theft-is-in-your-medical-records-not-credit-cards
If identity theft isn’t bad enough, erroneous information can end up getting into your file due to misuse (think blood type, allergies). If that happens, you could have a very bad time during an emergency room visit.
The big value is in blackmail, to mess around with people who hold national security clearances or control sensitive infrastructure.
But also picture these threats….
“Pay me $250 by bitcoin, or your neighbors will be contacted about your history of venereal diseases…”
“… HIV diagnosis …”
“… injuries sustained at a gay bar fight…”
Et cetera.
Very disturbing that a company had such a issue as ransomware and then allows such blatant carelessness to go unnoticed as unsecured files of personal data. “Try and figure out how this happened” Really? you have to figure out how this happened?
It appears that the individual documents are still all available and readable though Google’s cache.
I would have thought that a company suffering a data breach would immediately compile a list and submit that to Google to deindex \ remove the sensitive content.
From the Medantex “How it works” web page:
Security
Your data is kept on secure servers with 128-bit encryption, and we enforce strict protocols for safe and confidential handling of data. Your information is never at risk.
So I take it the data wasn’t even encrypted as claimed here?
Medantex: “Your data is kept on secure servers with 128-bit encryption […]”
Tom: “So I take it the data wasn’t even encrypted as claimed here?”
Heh! Their wording can be interpreted in more than one way. One is “Your data is kept on secure servers (but is not encrypted) and a 128-bit encryption ‘app’ resides on each of those servers (buried in a folder but unused).”
Sloppy wording on Medantex’s part. It does not clearly say that user data on their servers is encrypted. And there is much more that Medantex leaves unsaid.
(Anyone else notice that the name Medantex can be pronounced “Med-antics”?)
I’d lay odds that the ignoramus that put that on the site was not realizing that was the 128 bit encryption for SSL to access the site; which of course does not make the site secure at all – it just helps prevent “man in the middle” attacks while using the browser.
It’s just the usual marketing speak that usually has little relation to reality.
This is how technology marketing works. Put up a few words that vaguely reference some kind of encryption technology that you overheard one of the tech geeks mention, and the vast majority of people you interact with won’t even notice it’s BS. And not even good BS at that. When you get breached, “view with alarm” and promise to “look into how our super secure encrypted servers” were breached.
Marketing and PR types only know how to spin, they don’t know anything about the technology they are marketing, how it works, or even how to properly speak about it. They can BS the average Joe, but anyone that has half a clue will know it’s garbage market-speak-buzzwords.
So true! And so tiring! 🙁
Good article. Almost, dropped my coffee cup on one of the comments. Folks, these are the best and the brightest in the medical technology field. Where is security taught? Not in those schools, you got it, hippa is taught. Why? These are medical training schools, get it yet? Not security schools. Want to add another four years onto a medical degree? And then only be eight years behind in security? Lucky if they are near ten years behind right now and working at solutions for problems of then. Not now.
Now start assembling a list of medical practitioners, and the associated businesses, and notify them that you want to test their security. And see how it works. You will get some surprises. Then work your way to their training centers, and organizations, and while you are at it, remember, these places also handle your mom and pop…
And a second idea. Look at Slashdot, an article on symantic/ orangewood. The significant part of the article is imbedded xp. But, honestly, would you trust win10 on a pacemaker? Or a crash cart? The patient would be dead before the cart was usable, or still updating from the last known update. Next, how about Linux, or apple? No better, each restart, you have to check for updates according to the manufacturer prior to use. So, why choose win xp to use? It works first, your pacemaker will zap, your crash cart will show tracings of the EKG, first. That’s your vector, ease of entry, xp. Embeds in chips. Plus, these machines are incorperated into a medical network as primary items/ must record items.
So if they are getting into med records via remote desktop services, does this put a medical transcriptionist files at risk? Or worse, their computer?!
Brian,
I am not surprised by this. What does intrigue me is your reporting that Pydah is founder and CEO., but that is not how he is listed on their website. Pydah is shown in the company’s CA location. A Matthew Crook is listed for the company’s registered business location of Witchita, KS.
I also noticed that MEDantex is a division of Prosoft Systems Inc. Maybe they have information. The website also shows a location in the UK.
A quick people search on Spokeo of Matthew Crook returned locations in FL and KS. Going by 2 other aliases.
This story does seem a bit dubious.
The company does not look like it has a genuine presence in the various locations that is claiming.
The “parent” Prosoft Systems (prosoft-usa.com) also seems to a bit unclear what it is. Maybe they are based in India?
Banbreach also seems to have no verifiable information on its “website” .
Does this story need some more research?
“This story does seem a bit dubious.”
If all Mr. Krebs did was republish some accusation written by Banbreach, with no verification of the article’s content, then you might have a valid point. But that’s not what he does.
Everyone who has read this site for years knows that Brian does his own in-depth research and carefully documents his findings before posting anything about specific companies’ security failures. If you read this article, you will see that he investigated the problem, explored the potential for deletion and false changes of patient medical data, collected screenshots, reported the problem to MEDantex, and waited over the weekend so they could [try poorly to] resolve the problem before he published it here. When he did publish, he included screenshots documenting the exposure of information and access to processes that were supposed to be secured.
With all that, it would not matter if he first heard of it from a crack dealer under the bridge, or from a celebrity gossip Twitter feed. The reliability of the original referrer is no longer relevant.
The question is: Do we know whether any real customers have been affected by this?
A directory of names does not prove that they relate to real customers of (one-man band) Medantex.
This might be an attempt to draw attention to a non-entity, which is why the source is relevant.
My guess is that the medical facilities and doctor groups that you list have no idea that they are customers of MEDantex. The way it works is that shell companies get the contract for services, such as medical transcription, then shop around for a subcontractor to actually perform the service. And even the subs might seek out someone who can do the work for less. Look up the term “service arbitrage”
I would not be surprised if the actual transcription work is being performed in India. The web site is probably managed from India via Remote Desktop Connection. It’s no surprise that the ransomware used the same connection.
The site is back up and the security isn’t fixed at all:
-php is still there: https://medantex.com/transcripts/logincheck.php
-cert expired in 2016
-https is not wrap-around
-Site accepts 112-bit ciphers
These are just the tip, I’m sure there’s plenty more.
This is a joke. MEDantex obviously didn’t get an external audit done before putting the site back online, or even bother to close the hole that was used in the first place. They probably didn’t work to identify who’s info was stolen. What a complete joke.
If they don’t secure the Remote Desktop, they are just going to be hacked again. They need to use a VPN or at least a RDP gateway proxy.
When the Remote Desktop port is open, Microsoft allows unlimited authentication attempts. There is no protection for brute force attacks which will hit the RDP port with thousands upon thousands of authentication attempts. RDP brute-forcing is one of the most common ransomware tactics.
Don’t open Remote Desktop ports direct to the internet!
This! 100x! I’ve urged people for years in my public talks to get away from RDP, and you wouldn’t believe how many times security pros are like, “Really, we can’t use RDP anymore?”
How about Chrome Remote Desktop, is that OK?
Maybe LogMeIn; or if you are lucky Team Viewer. They are the only ones that come close to secure RDP, that I can think of.
Is any remote desktop secure? Quick generalization, no. If you can trust someone else on the, your, computer the same time as you are uploading your bank info, or your savings account info, or your payroll info. Then it is secure. Who knows when the remote can go active. Its called lurking, as in did it all go offline, just because you disconnected. Depending on the others setup, they have root privilege on your computer. Did they have a full hangup, did they plant something,
And, how many businesses, run xp pro, and are incorperated out of Delaware, with a pro box at someone’s house or office? What state is gm incorperated in and their headquarters and it staff located in? The important part is, did they learn from their mistake, this one may be in the process of learning, and that may take longer then first try-
Yet more worrying news regarding data protection. If an inside threat is the biggest risk, why not train staff at all levels regarding online security and data protection?
Companies seem to disregard cyber security until it’s too late.
I love you, Brian Krebs.
Why don’t we just go back to In-house medical transcription instead of outsourcing…. Greed versus security….
Medantex no longer exists, it would seem from the “Not Found” message on their website.
Krebs has singlehandedly put them out of business!
There is a huge difference between “website is down” and “company is out of business”. For example, MEDantex may have merely been attempting another update, hoping to resolve the malware infection that caused the security failure, when you looked at it.
I am anxiously awaiting to learn more about how and why the problems with Medantex occurred. Perhaps there is something I can learn from their situation to shore up my own systems.
I am a little surprised by some of the comments on this article. While the majority seem interested in adding something positive to the discussion a few definitely do not. Perhaps more disturbing though is the apparent lack of understanding that still seems to exist surrounding HIPAA and the value of personal medical information. I suppose that is to be expected though. It can be a complex issue.
This is what happens when you use pirated OS and unlicensed & refurbished firewalls.
Whatever is said, the GDPR sets a whole new level of security for personal data worldwide (yes, also for the USA). No one can avoid it as its principles are key. Taking GDPR is currently (probably) the most extensive and demanding requirement for companies to apply, it will instill the highest level of confidence by many users of GDPR compliant services.
Waywithwords.net and Nibity.com – transcription services we provide globally, are both being revised currently to absolutely comply with the rigorous demands of GDPR.
It is our view that companies not working to these standards will in time fall into the trap of distrust by their users.
It would seem, lack of understanding of personal medical information; I suppose infections, can be a complex issue, demanding confidence compliant services worldwide, as a requirement.