Dealing with open source coding can often be a double-edge sword in that the work sparks innovation and economic efficiency, but there’s also the notion to consider that some of the work may essentially provide an open-book cheat sheet for potential hackers. Doug Mackey, Georgia Tech graduate student illustrated this dichotomy as he worked on a research project involving the security of Veterans Health Information Systems and Technology Architecture (VistA), an open source EHR system.
Mackey, a CISSP who has a background in IT security with the Australia Department of Defense before moving to the U.S., found a VistA remote-access security flaw and eventually the US Department of Veterans Affairs (VA) and Open Source Electronic Health Agent (OSEHRA) collaborated on the vulnerability and create a patch to fix it.
With the intention of analyzing and studying the security of software used within a real system in a critical economic sector and looking at different industries, Mackey found healthcare and VistA to be an intriguing option. Because of VistA’s open source nature, independent researchers are able to review the source code without much difficulty. Using the source code, Mackey set up an isolated test system to test the system’s security and found a gap in the M2M Broker inside the VistA system. (It’s important to note that at no time did he touch a real, live VistA system that held patient data.)
I started out wanted to do a network security review of the VistA software and had no experience with the health systems prior to this project. In addition to the source code review, I conducted a sort of protocol fuzzing (a Black Box software testing technique) on my test system and I found a programming logic error. It wasn’t a buffer overflow, it was more of a programming oversight or logic error, which means that some remote messages are not properly security checked and a remote unauthenticated or unauthorized user can execute any of thousands of database operations. Since the systems aren’t connected to the internet, an adversary would first have to stage an operation to gain access to an internal network and then use the vulnerability to create havoc within a central database.
The patch. according to OSEHRA, introduces a new variable to designate whether the M2M Broker is required. Systems utilizing the DICOM Gateway, for instance, would require the broker and where the broker is required, the patch corrects the security deficiency and the broker is otherwise disabled. Don Hewitt, OSEHRA VP of business operations but also a CISSP, explained that it took OSEHRA and VA from June through early November to create a sound patch for the flaw.
One of the things that we were excited about [with the incident] was it was the first that we’ve seen a security issue arise from the [open source] community and report the flaw [to the VA and OSEHRA]. We view this as a validation of the fact that you can get better security with open source as you get more sets of eyes on the code. Because the community found the flaw, the logical place to work on it was OSEHRA. On one hand, it wasn’t an earth-shattering vulnerability because, among other things, you needed to be in a VA network to take advantage of the flaw. But someone internally could have exploited [the issue]. We treated this as a zero-day exploit. We didn’t want to announce the flaw until we had a patch and formed a working group, all of whom were under a non-disclosure agreement (NDA).
Future security concerns?
While the story does have a happy ending in that OSEHRA and VA were able to make the project a priority and create a patch without anyone knowing of the flaw beyond those involved in the project, detecting and handling these hidden vulnerabilities remains a concern, according to Mackey. “On one hand, open source coding spurs innovation and allows independent researchers to contribute,” he said. “But on the other, it allows potential adversaries to have significant insight into systems.”
It didn’t take Mackey long to find the flaw, as he was acting as an adversary, but the greater source of apprehension may have lied in the fact that the vulnerability was introduced in 2002 and had remained unknown and undetected until Mackey looked at it.
Some process is significantly broken. The first problem was that it was a patch to add some capability to the system that was urgently needed to support a new application and how something like that could be approved for deployment when it violates the VA’s own security policy. Why was this never fixed? It seems odd to me because you need to have the penetration testers that aren’t app developers that serve as independent actors. Those reviews need to be done in a structured, managed way.
