Your Medical Records Aren't Always Safe: The Important of Security in Medicine

Recently, I attended and presented at the 2012 Radiological Society of North America (RSNA) conference in Chicago, Illinois. RSNA is a massive gathering-- one of the largest in the world--and is a venue for manufacturers and medical software companies to show off the latest Radiology equipment and software. Being a software developer, I sought out several presentations by Radiology residents and graduate students that pertained to technology and medical software. During one of the hands on courses, in which the audience participated in the setup of web based Radiology software (including launching XAMPP and navigating PHPMyAdmin to view the MySQL table structure), I noticed something extremely peculiar.

While browsing the table structure of the users table, I noticed a database row (which was pre-populated during setup) containing an admin user. Among the columns were several standard entries, including the username, a flag indicating the admin status of the user, a URL, a…wait-- a URL? Normally, this wouldn't cause me to do a double take, except there was a curious string listed under the admin user's URL field. "password". I don't know about you, but to me, that looks nothing like a URL. At this point, the presenter hadn't gotten to logging into the admin panel-- she was still showing the database structure.

So, I navigated to the admin dashboard and entered "admin" as the username and "password" for the password. It worked, and I was logged in. Hoping this was mere coincidence, I proceeded to change the password of the admin user. I checked the database again-- "password" was now "hackme"-- the same string I changed the password to.

To verify my finding, I began to look into the code a little bit. Fortunately, the login form was sanitized through mysql_escape_string() to prevent against SQL injection. The programmer even acknowledged the blockage of SQL injection in the comments of the code, indicating that he or she was aware of the threat.

But diving a little deeper, in one of the pages that displayed a detailed information page for a specific data item, I noticed another problem:

$id = $_GET['id'];
$query = "SELECT * FROM reports WHERE id='$id'";
$result = mysql_query($query);

The variable, a GET variable none the less, is being inserted into the query without being sanitized. Luckily, it's not possible to simply pass '; DROP users into the GET variable because mysql_query() doesn't support stacked queries. As a bonus, the page doesn't check for authentication at all-- anyone with the URL can look at any number of reports whether they are logged in or not.

I also ran into these same issues in another piece of software demoed at the conference-- plain text passwords are stored in the database and (a lot) of SQL injection points. But looking through this second application, I also noticed something odd-- I didn't see $_GET or $_POST anywhere in the application. I searched through the files, and Sublime Text didn't return a single instance of either being used. Then it hit me-- the software was relying on PHP's register_globals. So, using the GET query strings, I could overwrite several parts of each SQL query.

So, are any of these things issues? After all, all of these applications are held within the hospital's intranet, which is locked down relatively tight. Of course they are.

Imagine if a disgruntled employee wanted to get revenge on his or her boss or coworkers-- a quick look in the database, and you've got their password to the reporting software. While this may not be the same password used everywhere else by this individual, you've minimally got a great starting point.

And what if the hospital's network is compromised, either due to a lost USB authenticator or an external intrusion? Then, you not only have the issue of patient data leaking, but you've possibly compromised the entire Radiology departments' passwords, which could lead to further intrusion into other, more secure software hosted on the intranet.

I do consider myself lucky for the amount of security knowledge I have-- something a lot of other developers never really have significant experience in. Fortunately, I've never had an intrusion into any of my projects or sites, and I largely attribute this to my paranoid nature in combination with this security knowledge. But these residents and students are primarily doctors-in-training-- not programmers. They don't have significant formal (or informal, since I've never really taken computer science classes before this year since it is a requirement in my major) training outside of, maybe, introductory computer science courses during their four years at a university (in most cases-- I know several Radiologists that are computer science majors). Programming is a hobby or a budding skill for them, and it shows. While this is certainly not anyone's fault (after all, we all started somewhere), it can potentially be dangerous in the medical field. It's not just customer data at stake-- it's the intimate personal details of the lives and heath of patients.

Note: I've omitted the majority of specific details of these applications, including the names and specific purposes.