Note: this article was written in 2017, an updated article on healthcare penetration testing is now available.
Web application security is a far more complex issue than many other areas of security. There is a high potential for applications to allow users to extract sensitive data, bypass authorization, and even execute commands on the system. But even applications that prevent these types of attacks are often found vulnerable to other “less direct” attacks. As we see time and time again, criminal hackers will go to extreme lengths of effort to profit in any way possible. As many know, healthcare is an industry which has (understandably) lagged in security. It has had an extreme need for technology development, and has never been an attractive target like banks were to criminals. Unfortunately, the rising black market value of medical records is changing this, and with it bringing more sophisticated attacks. And to see what is coming, we don’t need to look far. We can take a lesson from the financial industry, which has been the target of cutting edge attacks for the last two decades. As application security improves and attackers find themselves unable to gain direct access to systems, they will look to the next best thing: getting users to do the dirty work. These types of issues are heavily exploited in the financial world, an industry which has poured millions into ensuring applications are not susceptible to such attacks. These are most commonly known as a “confused deputy problem”, where a malicious actor persuades a victim into performing an action against their knowledge or will. Before we look at these attacks individually, it’s important to understand that all of these issues require several prerequisites in order to pose actual risk: 1. An application performing a sensitive operation. 2. An attacker with some prior knowledge of the application. 3. A user currently logged into the application.
Cross-site Request Forgery (CSRF)
Chances are at some point you’ve seen a URL that looks like this:
http://application/delete_record.asp?id=5
It performs a specific sensitive function, and takes predictable parameters. While this probably doesn’t seem like a big problem to most people, an attacker may exploit this to force a user to delete records within an application.
Let’s take a detailed look at the steps: 1. The attacker sends an email or message to the victim, convincing them to click a link to a website controlled by the attacker. 2. The user clicks the link, visiting the malicious website. 3. The attacker takes the URL that will perform a sensitive operation and embeds that link on the malicious site. 4. When the victim’s browser loads the content of the malicious site, it attempts to fetch the content embedded on the page. This causes the victim’s browser to make a request for this URL – because the user is already authenticated to the application, the operation is performed successfully without any knowledge of the user. You may be thinking “How is this a vulnerability? This is the way the web works” and you’re exactly right. For a long time this was just how applications were designed; and that was that. The ultimate weakness here is in the HTTP protocol itself, it was simply not designed for the fact that we would be using it for the most sensitive and life dependent operations that we do today. But in order to face reality, we must build applications that compensate for the weaknesses of all components, even the HTTP protocol itself.
ClickJacking (UI Redress Attack)
Similarly to CSRF, Clickjacking also persuades a user into performing an action against their will. In this scenario, the attacker creates a web page that embeds the target application within a frame. The attacker then creates a CSS overlay to mask the encapsulated application. The mask may include a JavaScript game which encourages the victim to click on areas of the screen, or enter data into form fields. What the victim doesn’t know is they are actually clicking and typing into an application they are already logged into.
It’s important to note that the risk of CSRF and Clickjacking can vary wildly, and there are several factors which may increase or decrease the risk: * Sensitivity of operations – An attacker must be able to benefit from a user performing certain actions. Can the application transfer money? Send a medical record? * Ability to target users – An attacker must be able to persuade users to visiting a website. A broad user base of an application will increase risk. * Inside knowledge – An attacker must have some inside knowledge of the application. Open source and widely distributed products have a significantly elevated risk because of this. The expanding health IT ecosystem drives all three of these factors higher in risk. As patient facing applications become more powerful, the more likely users will face these types of attacks. The good news is that both of these issues have well documented fixes which have been adopted into most development frameworks and web servers. Next week we will publish part 2 detailing mitigation strategies.