Is Your EHR Hackable?

by Jerome Carter on February 4, 2013 · 2 comments

Last month the Washington Post ran an article, Health-care Sector Vulnerable to Hackers, Researchers Say, which sounded alarms concerning the security of clinical systems.   Reflecting on the state of HIT security, the article quotes Avi Rubin, a security researcher:

I have never seen an industry with more gaping security holes,” said Avi Rubin, a computer scientist and technical director of the Information Security Institute at Johns Hopkins University. “If our financial industry regarded security the way the health-care sector does, I would stuff my cash in a mattress under my bed.

Of particular interest to me was this observation regarding OpenEMR:

OpenEMR, an open-source electronic medical records management system that is about to be adopted worldwide by the Peace Corps, has scores of security flaws that make it easy prey for hackers.

OpenEMR is a web-based system written in PHP and MySQL, a popular technology pair used for a number of web applications (including the one on which I am currently working).   Learning that OpenEMR has flaws is not shocking.  Web applications are complex systems and, like any complex system, identifying and removing all the bugs takes time.   OpenEMR’s chief of security is quoted as saying that,  “… his group fixes problems as soon as it learns about them and that other Web-based systems probably have the same weaknesses.”   I agree.  Open EMR is not alone.  Website hacks are a daily occurrence. Seemingly, every major site has been hacked at some point–just look at this list from 2011 alone.

The Usual Suspects
Of the many vulnerabilities that web applications may harbor, two of the most common  are cross-site scripting and SQL injection.  (EHR certification testing does not check for these vulnerabilities; therefore, certification offers no protection.)  Both problems stem from the same programming oversight—being too trusting of what users type into an application.

Practicing Safe Input
Web browsers parse HTML, CSS, or JavaScript code and render the result as a human-readable web page.  If the code being parsed is that written by the application’s developer, things are great. Problems arise when the parsed code is malicious HTML or JavaScript deposited on the site by a hacker.  Any data entry field set up for site visitors to enter information can provide a way in for malicious code.    These types of exploits can be prevented by validating and sanitizing input.

Validation simply means checking that the information entered matches the expected format (e.g., a SSN# is all numbers and formatted as xxx-xx-xxxx).   Sanitizing is a matter of making sure that user input contains no HTML, JavaScript, improper characters or other code that might compromise the website.  There are ways to do this in all web development languages; the programmer simply has to remember to do it.  Now that you know about malicious input, I’ll take a stab at explaining cross-site scripting and SQL injection, but first, a little about cookies and sessions.

When you visit a website what you are actually doing is requesting a page or resource (e.g., PDF, image, etc.).   Typically, the web server accepts the request, sends back the page or resource requested, then  immediately forgets that you exist.  This works fine if all you want to do is browse or download a file, but what if you are shopping?  In order to keep a shopping cart that remembers what you have until checkout,   there has to be a way to remember that you exist between requests.    Sessions and cookies solve this problem.  When you log onto a site, the web server creates a Session ID. Next, the Session ID is placed in a cookie, and the cookie is sent to your computer.    From that point on, the cookie accompanies every request sent to the website.   The session ID in the cookie is compared to the one on the server, and that’s how the web server knows who is making the request.

Cross-site scripting
Cross-site scripting (XSS) works as follows.   Let’s say that there is website, InnocentSite.Com, where visitors can ask questions.

  • HackerJoe types malicious JavaScript code into the question box along with his question and hits the Submit button.
  • Since InnocentSite.com forgot to validate/sanitize questions, the malicious JavaScript is inserted into InnocentSite.com.
  • When UnawareMary logs in to InnocentSite.com and she reads HackerJoe’s question, the malicious JavaScript code runs in her browser.   Typically, the malicious code tricks UnawareMary’s browser into sending her cookie to a bogus site run by HackerJoe.
  • Once HackerJoe has stolen the cookie, he can go to InnocentSite.com and pretend that he is UnawareMary.
  • If InnocentSite.com is a bank, then HackerJoe would have access to Mary’s account!  There is more than one way to do XSS (the scenario described here is the persistent form), but both methods make use of the same website weakness: failure to check for malicious code in user submitted information.

SQL Injection
SQL injection, as the name implies, involves tampering with SQL code used for database interactions.  A typical place one might see SQL injection is in a site’s registration form.  Malicious code that alters SQL queries may be inserted into form fields, which can damage the database or steal data.

As the article notes, health care has not been the focus of hacks to the same extent as other domains. Even so, this is hardly something in which to take comfort. Healthcare organizations, for the most part, have not been computerized to the same degree as have, for example, financial institutions, and thus have not been worth the effort.   However, within a few years, perhaps only three vendors will control the inpatient EHR market, and SaaS EHRs will harbor the records of a large number of outpatient practices.  As a result, hackers will only have to learn the weaknesses of a few systems in order to cause trouble.  Given what has happened in other sectors, I think it is safe to assume that once the move to digital records is far enough along, healthcare organizations will draw their share of attention.     A word to the wise…

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 2 comments… read them below or add one }

David W. Wormuth September 24, 2014 at 9:31 PM

One of my favorite cartoons and not XSS!

http://xkcd.com/327/

Reply

Jerome Carter September 24, 2014 at 10:09 PM

Love it!

Reply

Previous post:

Next post: