Securing hospitals from exploitation of hardware ports

Linköpings universitet

Linköping University | Department of Computer and Information Science

Bachelor thesis, 16 ECTS | Datateknik

202017 | LIU-IDA/LITH-EX-G--2017/078--SE

Securing hospitals from

ex-ploitation of hardware ports

Magnus Axetun

Supervisor : Marcus Bendtsen Examiner : Nahid Shahmehri

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c

Abstract

Electronic devices are widely used in today’s hospitals and the possibilities they offer are increasing every day. The devices are often embedded systems, running outdated operating systems and need to have a high uptime which makes them vulnerable to malicious software (malware). This thesis examines the ways malware can propagate through the Universal Serial Bus (USB) with the help of social engineering. Valuable assets are defined and different threat scenarios to these assets are presented. Lastly, the different scenarios are evaluated based on which assets they impact and how to effective mitigate the threats they present. Short- and long-term mitigations are presented to secure the devices in a broader view.

Contents

2.2 Social engineering . . . 3 2.3 Introduction to CORAS . . . 4 3 Method 6 3.1 Context Establishment . . . 6 3.2 Risk assessment . . . 9 4 Results 11 4.1 Risk estimation and evaluation . . . 11

4.2 Threat scenario 1 . . . 12 4.3 Threat scenario 2 . . . 14 4.4 Threat scenario 3 . . . 15 4.5 Risk treatment . . . 17 5 Discussion 19 5.1 Results . . . 19 5.2 Method . . . 20

5.3 The work in a wider context . . . 20

6 Conclusion 21 Bibliography 22 A Appendix A 24 A.1 Diagrams from risk assessment . . . 24

List of Figures

2.1 Symbols of the CORAS language . . . 4

3.1 An overview of the system . . . 7

3.2 Asset diagram with a hospital as stakeholder . . . 7

3.3 The risk evaluation criteria . . . 9

4.1 Risks classified within the risk evaluation criteria. . . 11

4.2 Auto play dialog box for windows XP . . . 16

4.3 Text from an autorun.inf file . . . 16

A.1 Threat scenarios with likelihood and consequence values. . . 25

List of Tables

3.1 Asset importance table . . . 8

3.2 Consequence scale for electronic health records . . . 8

3.3 Consequence scale for computers and medical devices . . . 9

3.4 Estimated likelihood scale . . . 9

4.1 Risks to direct assets. . . 12

1

Introduction

1.1

Background

The usage of electronic devices in hospitals is nothing new and will continue to be a part of the medical care in the future. While the electronic devices have become more and more advanced the possibilities for the hospitals have become wider and wider. The development gives the patients better health care and ease the work for the physicians. The drawback of this rapid development is that the security of the devices and the awareness of the users have not kept up in the development. When the patients’ journals goes from paper form to electronic form they become exposed to cyber criminals that may want to use them for malicious purposes. Most of the devices used today such as computers, printers, etc, have hardware ports, especially the Universal Serial Bus (USB) port. These ports are necessary for the devices to work properly but at the same time they can be used to infect a system with malicious software (malware). Viruses, trojans and worms can be spread through USB ports and with more devices in use, the number of infection vectors rise. The malware can be spread by removable media which can make every device inside a hospital a potential victim for infections. Even medical equipment is vulnerable for malware infections. According to [8], only 145 out of 535 health care organizations have medical device security included in their overall cyber security strategy. These numbers show that IT departments at hospitals are not aware of the threat compromised medical devices make against hospitals. This is a severe threat since patients all over the world could get harmed through these devices.

Hospitals handle sensitive data like electronic health records (EHRs) and since the digi-tization of this kind of data the accessibility to it has increased substantially. EHRs contain unique personally identifiable information that are valued high among cyber criminals. This has lead to criminals focusing their attention towards sensitive data and the price for the data on the black market has increased over the last years [6]. With the increased value of EHRs more criminals attempt to steal sensitive data.

1.2

Motivation

A number of attacks against health care providers have already been made with a drastic increase every year, often exceeding the last year’s count by 40 %, since 2009 [4]. In [5], Curtis Skinner and Sandra Maler reports that a hospital had to pay a ransom since a virus

1.3. Aim

encrypted the files inside the hospital’s system. In [7], ten honeypots that looked like medical device control systems were connected to the Internet, these systems got malware infections and were logged into from unknown hosts. In [14], a major health insurance company got their database breached and hackers stole information of approximately 80 million people.

1.3

Aim

The purpose of this thesis is to determine risks and treatments to the identified risks in a fic-tive scenario using assumptions based on the real world. To get a complete view of the target a risk analysis will be conducted. Every risk considered will involve exploitation of hardware ports for delivering malware alongside with deceiving the users through different Social En-gineering techniques. The outcome of the analysis aim to suggest mitigations towards the identified threats to reduce the number of attacks against hospitals.

2

Theory

In this chapter general information about hardware port exploitation, social engineering and an introduction to the risk analysis method is presented.

2.1

Distinction between targeted and untargeted attacks

There are several techniques for propagating malware including phishing, fake links to web-sites and by removable media like removable drives. For malicious parties there are advan-tages and disadvanadvan-tages with all the techniques. A distinction can be made between untar-geted and taruntar-geted attacks [6].

In untargeted attacks the intention is to reach as many victims as possible. In these kind of attacks spreading viruses through mail is advantageous since the simplicity of sending an email. This kind of propagation has no specific target for the malware to hit. It is efficient when the purpose of the virus is to get spread and can reach the whole world from one place. In targeted attacks the intention is to infect specific targets chosen by malicious parties. Here, removable drives are more common since the target for the malware is known and in some cases it may be easier to plug in a drive into a specific computer than it is to get someone to open an email from a specific computer. In the scenario with a hospital the most sensitive systems may be offline, not available to reach from any network. In this case, the only way to attack the system is to get physical access and, for instance, engage a removable drive containing malware.

2.2

Social engineering

The term social engineering can be used in a wide range of contexts but for this thesis it can be described as different techniques used by cyber criminals to lure unsuspecting users to take actions that are not for the users’ own good. Krombholz et al [9] talk about different social engineering techniques and how they have been used in the past. The techniques are a combination of social and technical approaches. The social part consists of gathering infor-mation through, for instance, deceiving victims to believe that the attacker can help the victim or by purported authority where the attacker manipulates the victim to expose sensitive in-formation. The technical part is often some kind of virus which gathers the information the

2.3. Introduction to CORAS

malicious party is looking for. Stasiukonis [16] performed an experiment where he scattered removable drives containing malware at a company’s area to see if the employees’ curiosity would make them use untrusted drives. The result from the experiment showed that 15 out of 20 drives were plugged into company computers and the malware had infected the system.

2.3

Introduction to CORAS

CORAS is a qualitative security risk analysis method that provides a customised language for threat and risk modelling that is inspired by the Unified Modelling Language (UML). The CORAS model will be used as a basis for the method used in this report. The symbols in Figure 2.1 are defined by the CORAS language, and are combined to form diagrams. CORAS consists of eight steps divided into three phases; context establishment, risk assessment and risk treatment. The eight steps are summarised below from the definition in [11].

Figure 2.1: Symbols of the CORAS language

1. Preparations for the analysis

Getting knowledge about the target for analysis, the assets needed to protect and the main concerns for the target. With this initial information a preliminary focus and scope of the analysis will be made.

2. Scope of the analysis / high-level analysis

A meeting with the customer where the customer presents what they want to protect and what their goals are with the analysis. A target description is undertaken that will be used later in the analysis.

3. Defining the target description

The analysis team presents their view of the target and identify the assets needed to protect. A high-level analysis is conducted to get a high-level overview of the risks at an enterprise level. The main threats, vulnerabilities and unwanted incidents are going to be identified during this step.

4. Approval of target description

An approval from the analysis team and the customer agreeing about assets, scope, focus and assumptions of the analysis. After this step all the documentation of the target should be complete and correct. A risk evaluation criteria is created to determine which risks that need further evaluation and a risk function depending on likelihood and consequence is decided for every direct asset.

2.3. Introduction to CORAS

Within the scope and focus of the analysis the risks of relevance are now going to be identified and documented. This is done as a workshop using structured brainstorm-ing, starting from the high-level analysis and from there a structured walk-through of the target is done to identify risks, threats and vulnerabilities.

6. Risk estimation

All identified risks are evaluated according to the unwanted incident they are leading to. The unwanted incidents are estimated based on the likelihood of it happening and what consequences it may result in. These values are together combined to estimate a risk level for the each of the identified risks.

7. Risk evaluation

All risks are evaluated if they are acceptable or not. Similar risks are accumulated and the risks that affect indirect assets are identified and estimated. The risks are put into a matrix based on its specific risk evaluation criteria and depending on where they are put they are considered acceptable or not.

8. Risk treatment

Risk treatment for all unacceptable risks is identified to lower the likelihood and/or consequence for the risks. This is done with cost-benefit in mind to see which treatments that are worth implementing.

3

Method

In this chapter the procedure of the work will be described. The work is based upon a fictive scenario that will be explained in Section 3.1. Furthermore, a workshop was held to identify threats and treatments to the threats and the setup of this workshop will be described. Finally the results from the workshop will be presented in Chapter 4.

3.1

Context Establishment

The first phase of the risk analysis is to establish the context. This phase contains the steps 1-4, from Section 2.3, which is the work needed to be done before starting the next phase, risk assessment. All estimations in the scenario are made by the author of the thesis after discussion with the supervisor and the seminar group to get them as realistic as possible.

3.1.1

Preparations for the analysis

The target of analysis is a fictive scenario based on assumptions about a hospital. The sce-nario includes patient rooms, surgery rooms, work stations, radiology rooms, sample-taking rooms, etc. In most of these rooms there are technological equipment like computers, x-ray machines and sampling devices and other medical equipment. Most of the devices are either connected to the internal network or connected to another device that is connected to the internal network. Since computers often are connected to the different devices they can be found everywhere at the hospital.

3.1.2

Scope of the analysis

The main focus of the risk analysis is to determine how vulnerable a hospital is to attacks based on exploitation of hardware ports. Since the hardware ports are physical, the focus will be on computers and other devices such as medical equipment that may be at risk for malware. The personnel included in the scope are those who work with access to these de-vices such as physicians and nurses.

Other kind of attacks like phishing and hackers breaking into the system are not in the scope of the analysis. They are relevant threats to a hospital but due to limited time they are not considered in this thesis.

3.1. Context Establishment

3.1.3

Defining the target for the analysis

An overview of the system can be seen in Figure 3.1. The internal network of a hospital connects all devices in the system to be able to retrieve information from databases and to send information between each other. Since devices can be found all over the hospital it may be hard to share/retrieve information in any other way than through the network. The ease of having everything connected to the network also has the downside that if the network is compromised everything is reachable for the attacker.

Figure 3.1: An overview of the system

3.1.3.1 Assets

An asset is defined as something that a party finds valuable and therefore needs to be pro-tected [11]. Assets are divided into direct assets and indirect assets.

Direct assets are assets that are harmed directly if a unwanted incident occurs. For exam-ple, electronic health records can be modified or stolen.

Indirect assets are harmed through a direct asset. For instance, if electronic health records are stolen from a hospital the public’s trust in that hospital may be damaged.

3.1. Context Establishment

The asset diagram used in the scenario is presented in Figure 3.2 with a hospital as stake-holder. An arrow from one asset to another indicates that the asset pointed at may be harmed if the asset pointed from gets harmed. Since the focus of the analysis lies on exploited hard-ware ports the direct assets identified are the computers and medical devices vulnerable for malware alongside with the health records that can be stolen. These are the assets that may be the focus for an attacker since it will lead to the information the attacker is looking for. The indirect assets identified are public trust, service availability and patient health. The patient health and public trust are of great importance since if the patients lose trust for the hospital it will not be able to continue be a health care provider. For example, if a patient’s electronic health record is modified the patient may receive wrong treatment and in worst case even die. This is why the asset electronic health records affect both the public trust and the patient health asset.

3.1.4

Approval of target

Defining asset importance aims to show which assets are most important relative to the other assets and to help prioritize between different threat scenarios. The most valuable assets should be focused on and their threat scenarios are thereby more interesting. Asset impor-tance is defined between 1 (highest imporimpor-tance) and 5 (lowest imporimpor-tance) where the assets that have the higher importance are considered to be focused on when considering risks and where the assets with the lower importance may have risks that are acceptable. The ranked assets are presented in Table 3.1.

Table 3.1: Asset importance table

Asset Importance Type

Electronic health record 1 Direct

Medical equipment 2 Direct

Computers 3 Direct

Public trust 2 Indirect

Service availability 4 Indirect

Patients’ health 1 Indirect

3.1.4.2 Consequence scale

Each direct asset has a consequence scale associated with it to be able to evaluate and compare the potential harm caused by the risks it is exposed of. The direct assets computers and medical devices have the same consequence scale since the scale is based on quantity and the electronic health record asset has it own consequence scale. The consequences combined with the likelihood of the consequences will result in an estimation of the risks and the risk evaluation criteria will be shown later in the report. The estimated consequence scales are defined in Tables 3.2 and 3.3.

Table 3.2: Consequence scale for electronic health records Consequence Description

Catastrophic 1000+ records are affected Major 100-999 records are affected Moderate 10-99 records are affected

Minor 1-9 records are affected Insignificant 0 records are affected

3.2. Risk assessment

Table 3.3: Consequence scale for computers and medical devices Consequence Description

Catastrophic 50+ devices are affected Major 20-49 devices are affected Moderate 5-19 devices are affected

Minor 1-4 devices are affected Insignificant 0 devices are affected

3.1.4.3 Likelihood scale

There have been attacks made against health care providers over the last years. Due to the nature of the attacks and unwillingness of showing weakness by health care providers it is hard to keep statistics over these attacks. The likelihood scale is thereby based on estimations. The likelihood scale is presented in figure 3.4

Table 3.4: Estimated likelihood scale Likelihood Description

Certain Monthly

Likely Several times a year Possible Once a year Unlikely Less than once a year

Rare Less than once a decade

3.1.4.4 Risk evaluation criteria

The risks will be separated as unacceptable or acceptable where unacceptable risks need to be evaluated. They are split as shown in figure 3.3 where the green cells are acceptable risks and where the red cells are unacceptable risks.

Figure 3.3: The risk evaluation criteria

3.2

Risk assessment

In the second phase the steps 5-7 will be covered. This phase will contain information about how the workshop was carried out as well as estimation and evaluation of the risks. The out-come of the workshop, the risk estimation and the risk evaluation together with treatments to the risks will be presented in Chapter 4.

The risk identification was organized as a workshop lasting one hour. The target team consisted of the author of this thesis alongside with five employees from the Swedish Na-tional Forensic Centre. The team was introduced to the scenario by a presentation based on the information in section 3.1. The workshop was asset-driven which means that the identi-fication of threats were solely focusing on protecting the assets.

3.2. Risk assessment

The threat scenarios different risk level have been determined by estimating the likelihood of them happening. Furthermore, the likelihood of the unwanted incidents are estimated based on the likelihood of the threat scenario/scenarios leading up to the unwanted incident. Lastly, the consequences to the direct assets are estimated.

The last part of the risk assessment consists of placing the risks inside the risk evaluation criteria based on the estimated risk level. Based on the position in the criteria the risks are considered as acceptable or unacceptable.

4

Results

In this chapter the results from the risk analysis will be presented. In order to suggest specific mitigations for the identified risks, we have chosen to couple each threat scenario with an existing malware. These malware are, W.32 Ramnit, Locky and Conficker/W32.Downadup. In section 4.2, 4.3 and 4.4 we will discuss these malware in order to later describe mitigations that may reduce the risk of infection. They are chosen because they can have a great impact on hospital computer systems. The scenarios combine social engineering with these malware to form complete threats.

4.1

Risk estimation and evaluation

Here the outcome of the steps six and seven is presented and afterwards the scenarios will be explained in detail. The risks will be estimated based on how likely it is that they will occur and what consequence may follow. Lastly, the risks will be evaluated to see if they are acceptable or not.

The result of the estimations are presented in Figure A.1 in appendix A. The way the indirect assets are harmed can be seen in Figure A.2 in appendix A.

The risks are placed inside the risk evaluation criteria as shown in Figure 4.1. The risks for direct assets are presented in Table 4.1 and for indirect assets in Table 4.2. None of the risks are acceptable except for the risk towards no service available. The most necessary risks to treat are those harming electronic health records and patient health since they are defined as the most important assets overall.

4.2. Threat scenario 1

Table 4.1: Risks to direct assets.

Abbreviation Description Likelihood Consequence

E-com Encryption of documents Likely Moderate

RC-Com Remote control over computer Rare Catastrophic L-EHR Leaked Electronic health records Unlikely Major C-MedDev Compromised medical device Rare Catastrophic

Table 4.2: Risks to indirect assets.

Abbreviation Description Likelihood Consequence

N-SA No Service available due to remote control over computers or encrypted documents

Rare Major

L-PT Loss of Public trust due to leaked Elec-tronic health records

Unlikely Major H-PH Harmed Patient health due to

compro-mised medical device

Possible Major

4.2

Threat scenario 1

In this scenario a virus will infect a computer and then spread through removable drives to other computers at the hospital. The virus will then allow the attacker to get remote control over computers and steal EHRs.

4.2.1

Virus W32.Ramnit

The following description of W32.Ramnit (Ramnit) is a summary from the white paper in [3]. W.32Ramnit has not been sen in a real attack against a hospital but due to its modularity it could very well be adapted to a real scenario and that is why W32.Ramnit is chosen.

Ramnit is a virus that can steal login credentials, allow remote access to the targeted com-puter and steal files from the comcom-puter depending on which modules it has downloaded from its command-and-control (C&C) server. A C&C server is a server that remotely sends commands to a network of compromised computers. The compromised computers can in re-turn send back information requested by the C&C server. Ramnit spreads through removable drives by copying itself to all drives it can access.

When Ramnit arrives at a computer it injects its own two dynamic-link libraries (DLLs), DLL_1 and DLL_2, into service host procceses to avoid beeing discovered. A dynamic linked library is defined as “a module that contains functions and data that can be used by another module (application or DLL)” in [2]. DLL’s purpose is to make applications functionality easier to update and reuse. The downside is that malicious DLLs can be injected into the system as in the case with Ramnit. The DLLs can not execute alone and they need a program to be ran from and this program is the service host program which only task is to run DLLs. The two components communicate through a named pipe. A named pipe is a “section of shared memory that processes use for communication” [12].

The DLL_1 component is responsible for storing/loading, encrypting/decrypting and ex-ecuting the modules requested from the C&C server. The modules are stored in an encrypted log file. DLL_2 is connected to the C&C server and recieves and executes commands. The commands DLL_2 can do are request modules, take screenshots and upload screenshots to the server.

4.2. Threat scenario 1

Ramnit can download different modules from its server, of which the spy module, the Vir-tual Network Computing (VNC) module and the drivescanner module are the most interesting ones. The whole list of modules can be found in [3].

The spy module allows Ramnit to inject web forms into the user’s browser and mimic a legitimate website’s appearance. When the forms are submitted they are transferred to Ramnit’s server through the DLLs and not to the website they appear to be transferred to.

The VNC module allows an attacker to take remote control over the infected computer. Ramnit does this by setting up a VNC server on the computer. The attacker can then connect to the server as a client and take control over the server. Keystrokes and mouse clicks now happens on the server as if the attacker where sitting in front of that computer.

The drivescanner module scans the computer for files that match file names listed in a configuration file provided from the server. In the beginning of the configuration file there is an inclusion section with entries that should be matched. The last part of the configuration file contains an exclusion section with the entries that should not be matched. These two sections can be modified to suit the purpose of the attack. The matched files are then sent to the server.

To propagate itself the virus scans all valid drives connected to the computer searching for either fixed or removable drives. Inside every of these drives Ramnit looks for files with the extensions .exe or .dll. If a file has either of the extensions the virus appends a new section in the file with code to decrypt, drop and launch Ramnit. The entry point of the file is changed to start at the newly added section and then jump back to the original entry point at the start of the file when the code of Ramnit has been executed. So when the files are used at another computer, Ramnit gets installed and the computer is infected.

4.2.2

Attack phase

An attacker could enter the hospital and seek out a reception to ask for help with printing a document. The attacker would ask the receptionist if it is possible to print a document that the attacker has on a removable drive. This removable drive would carry a document to be printed along with a copy of Ramnit disguised as a program file. With social engineering techniques the attacker would be allowed to plug in the drive. When the attacker opens the drive he quickly double-clicks the program file so Ramnit starts to get installed. After that, the attacker prints the document, remove the drive and leave the hospital. The computer would now be infected with Ramnit and making other computers vulnerable for infection. If a removable drive would be connected to the computer, the virus would infect files on the drive that are vulnerable to Ramnit. When the drive is removed and used at other computers at the hospital, they would get infected. This chain could continue and end up with many computers infected over time.

Once the attacker gets to the C&C server the attack against the hospital can begin. The attacker has two objectives to be done, collecting electronic health records and take control over the computer with stolen login credentials.

The first objective can be done by sending the drivescanner module to the infected com-puter. The drivescanner would scan the computer for files named according to the configu-ration file. The configuconfigu-ration file’s inclusion criteria would be file endings looking like the files containing health records and the exclusion criteria would be system files, DLL files, etc. When the files are collected they are sent to the C&C server.

The second objective can be achieved by setting up a fake version of the login site to the internal network on the computer. The site would look exactly the same as the legitimate one but when the forms are submitted they would be sent to the attacker. When the login credentials are acquired the VNC module could be used to gain control over the computer. The attacker now has everything needed to login to the internal network at the hospital from a remote computer.

4.3. Threat scenario 2

The computer would now be infected with the payload and the vulnerable assets would be electronic health records and computers. Depending on the permissions on the computer the whole internal network would now be at risk.

4.3

Threat scenario 2

In this scenario removable drives containing the ransomware Locky will be scattered in the rooms of the hospital and the curiousness of the employees’ will be exploited to get the virus launched at the hospital’s computers.

4.3.1

Ransomware Locky

The description of Locky is a summary of the blog posts in [10] and [1]. Locky has been chosen since it spreads through documents that can easily be placed on removable drives and Locky encrypts files across the network which makes it a severe threat for a large network inside of a hospital. Locky also targets health care as primary industry, according to [15].

Locky is a ransomware that encrypts data and demands a ransom to be able to get the data back again. It can encrypt a large amount of file extensions and it also encrypts data on network shares and local drives. To make it harder to restore the data, the ransomware changes the file names of the encrypted data. The ransomware is spread through Microsoft Word files containing malicious macros. When opened, the text will advise the reader to enable macros if the text is unreadable. If the macros are enabled a file will be downloaded and executed, the text will not become readable. The advise to enable macros are only there to lure an user so the malicious file can be ran. The downloaded and executed file is the Locky ransomware and it will start to encrypt the files on the computer including videos, images, Office files etc. While encrypting files, Locky will also execute a command that deletes all of the Volume Snapshot Service (VSS) files, also known as shadow copies. VSS is a technology that enables saving backup copies of files or volumes during runtime so when these files are deleted no backup from this service is available. The ransomware does not only encrypt data on the local computer, it also encrypts data on network shares and removable drives connected to the computer. Lastly the ransomware will create a note with information about what has happened and a link to the Locky Decrypter Page where a ransom can be paid to get the data back. There is no known way to get the data back except from paying the cyber criminals up to this date.

4.3.2

Attack phase

In this scenario, an attacker would place a Microsoft Word document on a removable drives marked with the logo of the hospital. The file on the drive would be named "Salary for de-partment X" where X would be the specific dede-partment where the removable drive is placed. The file’s content would look like something unreadable with the recommendation to enable macros if the text can not be read. The command to download Locky would also be hidden in the document.

The drives would be scattered over the hospital in corridors, workstations, parking lots and dining rooms. Always near places where the employees are moving and likely to spot them. The employees would get curious about what is on the drive, pick them up and plug them into the computers at the hospital. When hoping to get the text in right encoding by enabling macros, instead Locky would be downloaded and start to encrypt the files on the computer. If the computer would be connected to other computers through the internal net-work all of them would get their data encrypted.

Assets affected by this virus would be computers and electronic health records. Since Locky encrypts data on other computers as well, a large amount of computers may be at risk. Depending on the number of files reachable by the computer, a big part of the system can

4.4. Threat scenario 3

be locked down. This scenario could lead to that the whole system at the hospital would get taken down and no files could be used. If there are no backups the damage could be devastating in the long term and medication for all the patients would be wrong. Since the importance of the EHRs in a modern digital hospital the easiest way to get past the problem would be to pay the ransom. The ransom could be thousands of dollars but since the patients can not wait it might be the only option.

4.4

Threat scenario 3

In this scenario an insider working at the hospital with physical access to the medical devices will use a removable drive with malicious code on it to allow a backdoor to the internal net-work of the hospital. The code is an old malware that escapes modern anti-virus programs and thereby can be used as a backdoor. The malware is efficient at spreading and defending itself from being removed. When the malware has established its botnet it can receive addi-tional malware that can do more harm to the system. A botnet is a network of computers that receive commands from a single computer, making it act like one computer even though there are many computers involved. The botnet can forward these commands in two ways, either by the single computer sending commands to all the other computers or by using a peer-to-peer (P2P) network. A P2P network means that all computers inside the network acts as both a server and a client. There is no single computer sending all commands, instead all the com-puters are sending commands to each other until everyone has received the command to be executed [17]. By using a P2P network the botnet avoids a single point of failure.

4.4.1

Virus Conficker/W32.Downadup

The following description of Conficker, also called W32.Downadup is summarised from the white paper [13]. Conficker is chosen since it has been seen in the wild targeting medical equipment according to [18].

Conficker is a very sophisticated virus with great versatility and the goal for the virus is to create a botnet. This botnet can get updates from the attacker through a P2P network. There are five variants of the virus where the second one, Conficker.B, will be used in this scenario. Conficker.B is chosen since it has the ability to spread through removable drives.

When a drive containing Conficker.B is inserted to a computer a dialog box like the one in Figure 4.2 appears on the screen with options for what should happen next. Among the three options the two first ones looks similar to each other since they got the same icon and message about what happens if they are clicked on. The difference is that if the first option is clicked it will use a program on the drive and not the regular windows explorer choice. This program can be anything and will most likely not open the drive to see what files are on it. This manipulation can be done since the file can be configured manually to have any text and many different icons. To figure out what is going to happen if the first option is clicked can be done by looking inside the autorun.inf file on the drive. An example of an autorun.inf file can be seen in Figure 4.3. The first line states that this is an autorun file. The second line contains the message of what will happen if the autorun file is used. The third line is the path to find the icon that will be used in the dialog box. The fourth line details what will actually happen if the autorun.inf file is selected in the dialog box. For Conficker.B this line runs the process that executes DLLs and places Conficker.B libraries into the system memory to get executed. When these libraries are executed the computer gets infected. The last line tries to get the file executed without showing a dialog box similar to Figure 4.2. This can be done through a feature that allows automatic execution if this line is added in a autorun.inf file. If this this feature is disabled, the line will be ignored.

4.4. Threat scenario 3

Figure 4.2: Auto play dialog box for windows XP

Figure 4.3: Text from an autorun.inf file

4.4.2

NOVA Critical Care Express

One major concern for hospitals is that they are using medical devices with outdated operat-ing systems, like the CCX device. The CCX is a medical device manufactured by NOVA and used for biological testing to help diagnosing a patient, often in critical care situations. One type of test is an arterial blood gas test that is done to determine the amount of oxygen in the blood and how acid (pH) the blood is. The CCX device has Windows 2000 as operating system which makes it vulnerable for older malware that have been patched away over the past years. The old operating system is vulnerable for known flaws like autoplay attacks. At the time when the device was manufactured there were older threats that the manufacturers had to think of when designing new technology. Viruses like Conficker.B, used in scenario 3, may not have been created at that time and this is why the devices nowadays are vulnera-ble for these kind of viruses if they have not been patched during their lifetime. Unpatched systems are a big attack vector for cyber criminals since the systems are hard to update after they are installed [18]. It is hard for the IT-departments at the hospitals to secure these device since they are old and it is often the manufacturer that got access to the devices. So even if a device is acting suspicious the staff at the hospital may not have access to investigate the device unless they can get help from the manufacturer that has built the device [18].

4.4.3

Attack phase

An insider working at the hospital would prepare a removable drive with Conficker.B and bring it to the hospital. With physical access to where the equipment are the insider would only need to sneak in unseen and plug in the drive into the critical care express (CCX) device. Since the device runs windows 2000 it would automatically run the removable drive. Con-ficker.B would be installed on the device without human interaction and the attacker could leave the room after a few minutes. To make sure the attack will be successful the insider can

4.5. Risk treatment

plug in the drive into more devices and make sure the virus get a strong foothold inside the system. When the infection is done the insider can use the CCX device as a pivot point in the network and from that device move around unseen in the network.

Assets exploited by this virus are EHRs and medical devices. The medical devices that are infected by Conficker.B are not easy to detect. This comes from that the devices are embedded systems and the people who have access to them are the manufacturer’s employees [18]. So to be able to scan them for malware the staff at the hospital have to contact the manufacturer and have them scanning the devices. The EHRs saved on the CCX device can be sent to the attacker from the device which make them an easy target.

4.5

Risk treatment

The last phase consists of step 8 and here the treatments will be suggested. Virus-specific treatments are hard to come up with and often requires a high technical expertise which is hard for the hospital to afford. But for these viruses to be a threat they often need some kind of human interaction before they start to cause havoc. Efficient ways of reducing the human interaction part is to inform and educate the personnel to raise awareness about re-movable drives with unknown content. Treatments can be divided into two categories, short-and long-term treatments where short-term treatments refer to introduce awareness of cyber security and set up policies for the employees and long-term treatments can be to separate networks and obtain a good backup solution.

4.5.1

Policy, informative work and education

To be able to raise the awareness among the employees they have to get informed that this is a serious threat and even if it has not happened yet this might be a concern in the future if nothing happens. To make a hospital a secure workplace from an IT-perspective it is of great importance that the staff knows how to act with devices and systems. If the staff do not expect anything to be wrong it is hard to be cautious.

A course in cyber security can be held for all employees at the hospital that takes up what are the most concerning risks, handling of devices, etc. Clear policies need to be introduced in different areas including device handling and password strength. To reduce the risk of getting removable drives containing malware into the hospital there should be a policy that tells the personnel to not plug in any drive coming from an untrusted source. Drives like these should be advised to be taken to the IT-department where it is up to the IT-personnel to decide whether or not the source can be trusted. By following a policy similar to this one no untrusted drives should be able to get into the hospital system. A password policy regarding devices bought from a manufacturer should be that no default password should be allowed. Often when devices are delivered they come with a default password that can be found online in the service manual of the device. If this password is not changed it is easy for an attacker to get the password and by that get access to the device. To change these default passwords are very important.

4.5.2

Network segmentation

To be able to have secure networks inside the hospital the networks need to be divided with a clear purpose. One way can be to divide the networks by the assets they protect. The net-works that do not protect any assets e.g. public netnet-works for guests at the hospital do not have to be highly secured since there is nothing to protect. Since these networks are meant only for patients and guests it should be impossible to reach sensitive data directly from them. Further, networks that employees use to work with need to have access to databases containing sensitive data should be private. They should have password protection and the access to the databases should be kept at a minimum so they only reach what is necessary

4.5. Risk treatment

to be able to fulfill their work. Lastly, networks for medical devices that almost solely han-dles sensitive data should be restricted to only be able to communicate with the computers monitoring the data from the device and should not have Internet access. Besides the net-works at the hospital it is substantial to reject connections from the Internet if they can not be trusted. For remote access to the hospital networks a policy is important to have in place. This is due to if an attacker get a foothold in some network of the hospital he should not be able to move around inside several networks of the hospital. When dividing the networks it becomes harder for a malicious party to find the sensitive data it is looking for.

4.5.3

Architecture of the system

Since hospitals often are large and there are many computers across the area it is hard to protect these devices from physical attacks. It is impossible to prohibit patients and guests to all areas where computers can be found. One way to solve this issue might be to rethink the architecture of the computers. Instead of having computers that can do several things they can be exchanged for thin clients that do have a more specific task and do not have permission to reach any sensitive information. Furthermore, these clients could be restricted to only communicate with the server they are connected to. With this restriction, there would be no need for the client to allow removable drives to be connected to the device and therefore the client would not have any USB ports. This would lead to that by only changing the architecture USB attacks against this part of the system would be prevented.

4.5.4

Secure removable drives

Employees often use removable drives collected from events, purchased private or just found somewhere. From the hospitals’ view these drives can be seen as untrusted since they can not assure the drives are free from malware. One approach to mitigate the use of untrusted drives is to use signed and encrypted drives. Software can be installed on the hospitals’ computers to allow certain removable drives that are confirmed to be trusted. Administrators can then set up a framework for which information that can be transferred, who are allowed to move information and deny access to all drives that are not trusted with the help of the software. Encrypted removable drives can then be added to the system and be marked as trusted so they are usable at the hospitals. With this approach, information would be secured if it is moved between computers inside the hospitals. The encrypted drives guarantee that even if a drive is stolen the information on it is encrypted and can not be used by malicious parties.

5

Discussion

In this chapter the results from the risk analysis will be evaluated, the method will be dis-cussed and the work will be look from a wider perspective.

5.1

Results

This thesis is a first step to focus the attention towards cyber security of hospitals and make them look over their systems and policies to be sure they are up to date. The usage of old operating systems inside medical devices are alarming since criminals have discovered this and turned their attention towards it. These old devices need to be analyzed to determine if they are safe or not for continued usage. The personnel at the hospitals must also get used to have to deal with cyber security in the future. More and more technology is introduced to hospitals around the world and needs to be handled correctly so the number of incidents are kept at a minimum. It is important to highlight the risks towards hospitals so it gets the attention required to be dealt with, both from the hospitals themselves and from cyber security experts.

The results from Chapter 4 demonstrate that most of the scenarios are not acceptable, which is alarming. Since the attacks include combined social and technical approaches the hospitals need to have this in mind when setting up their cyber defences. A solid defence will be a both expensive and time consuming to maintain, and hospitals may have problems to afford it. Because of this, it is important to focus on the parts of the defence that is most cost-effective. To educate and inform employees of the importance of cyber security is not very expensive but can be very helpful. For example, in both the first and second scenario the attacks may be successful because of that unaware employees are letting untrusted de-vices get engaged to the hospital’s system. These attacks could have been avoided if the employees would have known how to react when handling with untrusted devices by, for instance, following a policy determined by the IT-department. On the other hand, the tech-nical treatments are more reliable. If an employee does not follow a policy or as in the third scenario where an insider tries to compromise devices, the whole system may be at risk. So if an employee or insider tries to engage an untrusted removable drive and there is a software program denying the drive to get engaged the attack is repelled. Of course this is a more convenient defence than the policy but it is also a more expensive choice. The more technical approaches are often harder to implement and requires a well defined plan to get the most

5.2. Method

out of them. The less expensive ones may be a proper start for securing hospitals against cyber attacks. Hospitals need to find solutions that are cost-effective for them and they may vary from hospital to hospital.

5.2

Method

According to CORAS there should be approximately three workshops when doing a risk analysis like this one. Due to limited time there was only one seminar and the results may have been different if more seminars would have been held. Furthermore, CORAS is devel-oped for real scenarios involving a customer. To have a real customer involved in this thesis might have made some of the estimations better.

The reason to choose CORAS was to get broader view of the scenario and be able to quantify and estimate the risks, thereby get more reflections of the target. This thesis could have been done as a literature review to see which type of incidents that are most common and which ones that are most concerning for hospitals. The difference would have been that if a literature review was made it would not include the reflections from the seminar which was used to see the target from different angles.

The scientific literature about malware does often focus on the spreading of malware ac-cording to statistical models. There have not been many papers about how the malware works or how cyber criminals use it to their advantage. This is the type of information that anti-virus companies are interested in, thus researchers at these companies investigate the viruses and publish their results. This is the reason why many of the sources are from anti-virus blogs, white papers etc. The subject is also fast moving and papers published about viruses are often out-dated and the interesting information can be found on the Internet.

5.3

The work in a wider context

When examining malware there is always an ethical risk, since malware is meant to cause harm. In this case, it can cause severe damage not only to the system it attacks but to humans as well. Hospitals have very sensitive information about a large part of the population. It is important that they can keep this information so it does not leak out because then people in general would lose trust for the hospitals. But to know how to prevent malicious parties to succeed the security community needs to examine malware, for a good reason. When the malware is examined it is easier to find treatments to it and by that prevent malicious parties to succeed. Then the health care providers can focus on their job without having to be concerned about cyber attacks against them.

6

Conclusion

In this thesis, a number of threat scenarios to hospitals have been identified and described focusing on exploitation of hardware ports. The outcome shows that there are certain threats against hospitals and that they need mitigation. The mitigation need to consist of different approaches to get a solid defence and will take time to achieve. The suggested mitigations in this thesis are a good way to start dealing with the threats. They consist of both short-and long-term mitigations short-and some of them are quite easy but helpful to implement. One short-term mitigation can be to introduce the topic of cyber security among employees work-ing at hospitals to help them become more cautious about security risks. Since the human interaction part were exploited in the scenarios through social engineering, the employees need to be more aware and act proper if an attack is happening. The hospitals can become a secure workplace from an IT-perspective but it will require solid budgets and knowledge from cyber security experts to be able to afford it.

Bibliography

[1] Lawrence Abrams. Locky ransomware information, help guide and FAQ. 2016.URL: http: / / www . bleepingcomputer . com / virus removal / locky ransomware -information-help.

[2] Microsoft Corporation. Definition: Dynamic-Link Libraries. 2015.URL: https://msdn.

microsoft . com / en - us / library / windows / desktop / ms682589(v = vs . 85 ) .aspx.

[3] Symantec Corporation. White paper: W32.Ramnit analysis. 2015. URL: http : / / www . symantec.com/content/en/us/enterprise/media/security_response/ whitepapers/w32-ramnit-analysis.pdf.

[4] Institute for Critical Infrastructure Technology. Hacking healthcare IT in 2016. 2016.URL: http : / / icitech . org / wp content / uploads / 2016 / 01 / ICIT Brief -Hacking-Healthcare-IT-in-2016.pdf.

[5] Sandra Maler Curtis Skinner. Los Angeles hospital paid hackers $17,000 ransom in bitcoins. 2016.URL: http://www.reuters.com/article/us-california-hospital-cyberattack-idUSKCN0VR085.

[6] Independent Security Evaluators. Securing Hospitals. 2016. URL: https : / / securityevaluators.com/hospitalhack/securing_hospitals.pdf. [7] Kashmir Hill. Iranian hackers broke into what they thought was a Chevron gas pump — but

it was a honeypot. 2015.URL: https://splinternews.com/iranian- hackers-broke-into-what-they-thought-was-a-chev-1793849928.

[8] Ponemon institute. The state of cybersecurity in healthcare organizations in 2016. 2016.URL: https : / / cdn2 . esetstatic . com / eset / US / resources / docs / white -papers/State_of_Healthcare_Cybersecurity_Study.pdf.

[9] Katharina Krombholz, Heidelinde Hobel, Markus Huber, and Edgar Weippl. “Ad-vanced social engineering attacks”. In: Journal of Information Security and Applications 22 (2015). Special Issue on Security of Information and Networks, pp. 113–122.ISSN: 2214-2126.DOI: http://dx.doi.org/10.1016/j.jisa.2014.09.005.URL: http: //www.sciencedirect.com/science/article/pii/S2214212614001343. [10] Kaspersky Lab. Locky: the encryptor taking the world by storm. 2016. URL: https : / /

securelist.com/blog/research/74398/locky- the- encryptor- taking-the-world-by-storm/.

Bibliography

[11] Mass Soldal Lund, Bjørnar Solhaug, and Ketil Stølen. Model-driven risk analysis: the CORAS approach. Springer Science & Business Media, 2010.

[12] Microsoft. Pipe definition.URL: https://msdn.microsoft.com/en-us/library/ windows/desktop/aa365780(v=vs.85).aspx.

[13] Ben Nahorney. The downadup codex. 2009. URL: http : / / www . symantec . com /

content / en / us / enterprise / media / security _ response / whitepapers / the_downadup_codex_ed2.pdf.

[14] Adam Rubenfire. Hackers breach Anthem; 80M exposed. 2015. URL: http : / / www . modernhealthcare.com/article/20150204/NEWS/302049928.

[15] Mathew J. Schwartz. Retooled Locky Ransomware Pummels Healthcare Sector. 2016.URL: https : / / www . bankinfosecurity . com / retooled locky ransomware -pummels-healthcare-sector-a-9347.

[16] Steve Stasiukonis. Social engineering, the USB Way. 2006. URL: http : / / www . darkreading . com / attacks breaches / social engineering the usb -way/d/d-id/1128081.

[17] Techterms. Peer-to-peer definition.URL: http://techterms.com/definition/p2p.

[18] Inc. TrapX Labs - A division of TrapX Security. Anatomy of an attack medjack (Medi-cal Device Hijack). 2015. URL: http : / / deceive . trapx . com / rs / 929 JEW -675/images/AOA_Report_TrapX_AnatomyOfAttack- MEDJACK.pdf?aliId= 1417716.

A

Appendix A

A.1. Diagrams from risk assessment

A.1. Diagrams from risk assessment