Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

(1)

IN THE FIELD OF TECHNOLOGY DEGREE PROJECT

INFORMATION AND COMMUNICATION TECHNOLOGY AND THE MAIN FIELD OF STUDY

COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2020,

Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

EMMA GOOD

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

(2)

(3)

Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

EMMA GOOD

Master in Computer Science Date: July 5, 2020

Supervisor: Pontus Johnson Examiner: Mathias Ekstedt

School of Electrical Engineering and Computer Science Swedish title: Säkerhetsanalys av en Siemens SICAM CMIC fjärrterminal

(4)

(5)

iii

Abstract

In the power industry, electrical grids are undergoing a modernization into smart grids. The new smart grids integrate the electrical grid and information and communication technologies, such as software, automation, and information processing. While enabling remote communication with devices on the grid, putting the grid online also introduces some major problems, such as the risk of being the target of cyber attacks.

In this thesis, a security analysis of the Siemens SICAM CMIC CP-8000 remote terminal unit, used for remote monitoring and automation of electrical grids is done. Threat modeling was done to identify vulnerabilities in the system, followed by a penetration test of the web interface, used to configure the device, as well as a couple of network attacks. During the penetration test, two cross-site scripting vulnerabilities were discovered, one of which could allow an unauthorized attacker to execute Javascript code in the victim’s browser. It was also discovered that a user’s login credentials are leaked in the browser console in cleartext when logging in.

Keywords: remote terminal unit; RTU; penetration testing; smart grids;

security

(6)

iv

Sammanfattning

I kraftindustrin genomgår elnät en modernisering till smarta elnät. De nya smarta elnäten integrerar elnät och informations- och kommunkationstekno- logi, såsom mjukvara, automatisering, och informationsbehandling. Även om det möjliggör fjärrkommunikation så introduceras även stora problem när el- näten blir uppkopplade, till exempel risken att bli utsatt för cyberattacker.

I detta examensarbete utfördes en säkerhetsanalys av en SICAM CMIC CP- 8000 fjärrterminal, tillverkad av Siemens, som används för fjärrstyrning och automatisering av elnät. En hotmodell för att identifiera sårbarheter i systemet gjordes, följt av penetrationstesting av hemsidan som används för att konfigu- rera enheten, samt några nätverksattacker. Under penetrationstestningen hitta- des två cross-site scripting-sårbarheter, där den ena kunde tillåta en oautentise- rad angripare att exekvera Javascript-kod i offrets webbläsare. Det upptäcktes även att en användares inloggningsuppgifter läcktes i webbläsarens konsol i klartext när användaren loggar in.

Nyckelord: fjärrterminal; penetrationstestning; smarta elnät; säkerhet

(7)

v

List of Acronyms

BeEF The Browser Exploitation Framework CBC Cipher-Block Chaining

CVE Common Vulnerabilities and Exposures DoS Denial of Service

HTTP HyperText Transfer Protocol ICS Industrial Control System IETF Internet Engineering Task Force

IP Internet Protocol

IPsec Internet Protocol Security IV Initialization Vector LAN Local Area Network MitM Man-in-the-Middle

NTP Network Time Protocol

OWASP Open Web Application Security Project PLC Programmable Logic Controller

POODLE Padding Oracle On Downgraded Legacy Encryption RADIUS Remote Authentication Dial-In User Service

RTU Remote Terminal Unit RTOS Real-Time Operating System

SCADA Supervisory Control and Data Acquisition SSL Secure Sockets Layer

TFTP Trivial File Transfer Protocol TLS Transport Layer Security

(8)

vi

VPN Virtual Private Network WAN Wide Area Network

XSS Cross-Site Scripting

(9)

Chapter 1 Introduction

Due to the developments in communication technology in the recent years, more electronic devices are becoming connected, both at home and in the industry. In the power industry, electrical grids are undergoing a modernization into smart grids. The concept of smart grids can be defined as an integration of the electrical grid and embedded or decentralized information and communication technologies, such as software, automation, and information processing [1]. This new connected layer to the electrical grid enables remote communication with devices controlling the power on the grid, and is useful when it comes to monitoring and automation. While putting the electrical grid online has many benefits, it also introduces some major problems. Different kinds of devices have been used for a long time to control the power on the grid, and have always been possible targets for attacks. By putting the control and monitoring devices on the grid online, they become susceptible to cyber attacks as well.

While being the target of a cyber attack could mean big losses for a company, a cyber attack targeting the electrical grid could affect not only the power company itself, but also their customers. In December 2015, a cyber attack targeting an Ukrainian electricity distribution company caused power outages for around 230 000 customers lasting several hours. The attackers had gained remote control of the distribution management system in order to open breakers and take down several distribution substations. [2] The cyber attack in Ukraine is the first publicly acknowledged security incident to cause power outages, but due to the continued development in smart grid technology, it will probably not be the last. While the power outages in Ukraine only lasted for a few hours, it is possible that a future cyber attack could cause power outages over a longer

1

(14)

2 CHAPTER 1. INTRODUCTION

time, which would disrupt a lot of society. In order to avoid such incidents in the future, the security in industrial control systems (ICS) must become a bigger priority. This includes not only the IT-system and networks themselves, but also the connected devices in the system, since they could be used as points of entry into the ICS.

1.1 Problem statement

One type of device commonly used on the electrical grid is remote terminal units (RTU), that allows for remote monitoring and automation of the electrical grid. If malicious actors were to take control of the RTU they could cause disruptions on the electrical grid.

This thesis will evaluate the security of a Siemens SICAM CMIC remote terminal unit. The work aims to conduct a vulnerability assessment of the RTU in order to potentially find vulnerabilities in the device.

1.2 Research question

The question to be examined is: What kind of vulnerabilities is present in the RTU, and how can they be exploited?

1.3 Methods

The first part of the project will consist of examining current security research conducted on RTU and similar devices. A threat model of the system under evaluation will be done in order to understand it better and to identify potential weaknesses and attack vectors. Once the attack vectors have been identified, a literature study on related vulnerabilities will be conducted. Following the literature study, the security of the system will be evaluated by performing a penetration test on the identified attack surfaces.

1.4 Delimitations

The focus of the vulnerability assessment will be on the SICAM WEB tool running on the RTU, as well as the SD-card containing the firmware of the device.

(15)

CHAPTER 1. INTRODUCTION 3

Physically disassembling and hacking the hardware of the device will be con- sidered outside the scope of the project.

1.5 Outline

Chapter 2 will provide an introduction to RTUs and their security and general, the RTU under evaluation in particular, as well as previous work done in the field. Chapter 3 will describe the methodology used during the thesis work.

Chapter 4 will describe the threat modeling done and its results. Chapter 5 will give a theoretical background to the chosen attack surfaces. Chapter 6 will describe the results of the penetration testing. Chapter 7 contains the final discussion and conclusion of the report.

(16)

Chapter 2 Background

This chapter will provide an introduction to RTUs in general, and the current state of RTU security. The Siemens SICAM CMIC CP-8000 RTU to be evaluated in the thesis will also be described in detail.

2.1 Remote Terminal Units

A remote terminal unit (RTU) is a device containing a microprocessor that connects devices in the field to control systems such as supervisory control and data acquisition (SCADA) systems [3]. An RTU can monitor and control connected devices by sending telemetry data to the control system, and changing the state of the devices based on control messages received from the control system. One feature often found in RTUs is the ability to make custom programs in order to automate certain processes. This is useful for executing functionality that might not be practical to carry out remotely through the control system, such as functionality that is time-sensitive, or data-intense.

A variety of different protocols are used to communicate with RTUs, where MODBUS is one of the more common ones [4]. RTUs are commonly used in remote locations and in environments with extreme temperature due to their high operational temperature range. [3].

A device very similar to an RTU is the programmable logic controller (PLC).

As the name suggests, the logic in a PLC can be programmed to perform specific actions based on the input it receives from the controlled process. The biggest difference between PLCs and RTUs is that RTUs are often used in remote locations and can support rougher environments, while PLCs are commonly used more locally. PLCs and RTUs often support the similar features,

4

(17)

CHAPTER 2. BACKGROUND 5

such as the same industrial protocols for communication. Therefore vulnerabilities found in a PLC could also potentially be found in an RTU, and vice versa.

2.1.1 Security considerations

The intention of connecting an RTU or other field devices to the company network is to make it easier for the technicians to access the devices remotely.

Businesswise, this is easy to justify, since sending out technicians in the field to access the devices is a lot more costly than doing it remotely. While this might be good for the efficiency of the company, these connected devices become potential entry points for cyber attacks. If a malicious actor attacks an RTU or PLC, and gains root or admin access, that device can then be used to pivot to other systems, including devices on the wired, wireless, and serial networks. This puts the entire system at risk of being compromised due to weak security in one component of the ICS. [5] Other than using a compromised RTU or PLC to reach the system, an attacker could potentially do a lot of damage just by having access to the device itself. A successful attack could allow the attacker to change application configurations and programmable logic,and report false information to the operators. Depending on the processes controlled by the RTU or PLC, the consequences can range from interruption of operations, alteration of a process, or sabotage meant to cause harm, resulting in environmental damage (such as fire or oil spill), injury, blackouts, or explo- sions causing massive damage. [6]

One of the most well known attacks of this kind is the Stuxnet worm that was discovered in 2010. Stuxnet was the first known worm to target SCADA systems, and proved to the world what damage that could be done to SCADA systems by a motivated attacker. The target of the attack was an uranium en- richment facility in Iran, and more specifically the high-speed centrifuges used to enrich uranium. The centrifuges were controlled and monitored by S7-400 PLCs manufactured by Siemens, and the PLCs were in turn controlled and programmed using Siemens Step7 software. The Stuxnet worm sought out computers using the Step7 software at the facility, and used it to compromise the PLCs controlling the centrifuges. After taking control of the PLCs, they were used to make the centrifuges spin so fast that they broke down, all while providing false information to the outside controllers in order to make sure that they would not discover that anything was wrong until it was too late. [7]

[8]

(18)

6 CHAPTER 2. BACKGROUND

One of the challenges in securing RTUs and similar field devices is that many of the protocols used are old and were developed at a time where security was not a priority. Many protocols are vulnerable by design, and often lack encryption and authentication features. [5] This may previously not have been a big problem, since the devices were connected directly to the SCADA system and could not be accessed remotely. However, due to the recent shift in the industry to connect devices to the internet and communicating with them from outside of the SCADA system, this makes the lack of security in the communication protocols more serious.

2.2 SICAM CMIC RTU

The RTU that will be evaluated in the project is the SICAM CMIC CP-8000, which is manufactured by Siemens and part of the SICAM A8000 series. The RTU is shown in figure 2.1. The device is described by Siemens as a "telecon- trol and grid automation system for use in electrical power supply" [9]. The RTU is the basis in a modular system, which includes various binary and ana- log input and output expansion modules that can be combined with the RTU for different use cases. There are two possible ways for the RTU to communicate with the control center; multi-point connections (using RS-232 or RS-485 serial interfaces) or via LAN/WAN using Ethernet cables. Due to this, several different communication protocols are supported to provide additional flexi- bility.

Communication between the operator and the device can be done in two ways;

either via the program SICAM TOOLBOX II, available from Siemens, or via SICAM WEB, a website that is hosted on the RTU. The toolbox program can be used for all stages of configuration and maintenance. The functionality includes collection of data, configuring the system, changing device parameters, programming operating logic, testing, documentation, and system diagnostics.

The program is available upon request from Siemens and requires a licence to be used.

The CP-8000 RTU provides an integrated web server that hosts the SICAM WEB website. Since it is a regular website, no extra tools or licences are required. The web interface has some restrictions when it comes to configuration and maintenance, and not all functionalities available in the the toolbox program are supported.

(19)

Figure 2.1: The Siemens SICAM CMIC CP-8000 RTU [10]

All of the data in the device, such as firmware and parameter configurations, are stored in an SD card in the RTU that can be changed. When the RTU is started, the data on the SD card is checked, and if there is any change to the device settings, the new settings stored on the SD card are automatically trans- ferred to the RTU, enabling plug-and-play functionality. This method is also used for firmware updates to the system. When using the toolbox program or the web interface, configurations can be saved as a file and written to the SD card from the engineering computer. The configuration file can also be loaded into the device using TFTP (Trivial File Transfer Protocol), which is a protocol used to download or upload files. If the feature is used, the address of a TFTP server containing the configuration file is specified in the device settings, from which the RTU will download the configuration file and apply the settings specified in it. [11]

2.2.1 Security

Several security measures are implemented in the RTU to try to mitigate cyber attacks. The hardware contains an integrated "crypto chip" which "protects all data in a safe environment" [9]. The crypto chip is likely referring to a crypto processor, which is a specialized type of processor used to execute crypto-

(20)

graphic algorithms. [12]

To ensure safe communication between the RTU and the control center, the RTU supports the use of IPsec VPN tunnels. IPsec is a protocol suite used for protecting IP packets, and has two modes; tunnel and transport. Tunnel is the mode used in the RTU, which encrypts the entire IP packet to be sent and adds a new IP header. This is used to create a virtual private network (VPN) between the RTU and the control center. [13] In order to use IPsec VPN, it needs to be activated in the device settings. When it is activated, it also automatically activates a firewall, only allowing activated services to pass through.

[11] On top of the IPsec VPN functionality, all of the communication between the toolbox program/web interface and the RTU is done via HTTPS by default.

[10]

All security-relevant events that happen in the RTU are logged using SysLog, which is a standard for message logging. [14] The RTU has a SysLog client that transmits information about every event to a SysLog server. [11] The Sys- Log client is disabled by default.

The web interface for the RTU supports two different methods for authentication, via locally stored credentials or via an external service. If authentication via locally stored credentials is used, the entered login credentials will be compared with the locally stored credentials and log the user in if they match.

If external authentication is enabled, the authentication is done via an external RADIUS server. This requires that the IP address and the shared key of the RADIUS server are added in the web interface settings. [11] RADIUS (Re- mote Authentication Dial-In User Service) is a protocol used for transporting authentication, authorization, and configuration information between a server (in this case the RTU) that wants to authenticate connections, and an authentication server. [15] After the login credentials have been entered by the user, the RTU will send them in an authentication request to the RADIUS authentication server, which will compare the received credentials to the ones stored on the server. If the credentials match, the RADIUS server will return the specific user role to the RTU which will pass it to the web interface. This authentication process is illustrated in 2.2. If the RADIUS server could not be accessed and the fallback option is enabled, the RTU will use locally stored credentials. If the fallback is not enabled, the login will fail. [11]

(21)

Figure 2.2: RADIUS authentication in the CP-8000 RTU [11]

To ensure the integrity of the firmware and configuration files upon initialization and updates, the RTU verifies the files before loading them to make sure that they have not been manipulated. In order to do this "a cryptologic hash function is calculated over the file and the result is compared with the hash value in the filename" [11].

2.3 Related works

At the security conference BlackHat in 2011, security researcher Dillon Beres- ford demonstrated vulnerabilities he had found in the Siemens Simatic S7- 1200 and S7-300 PLCs. The vulnerabilities included being able to send control messages while making it look like they came from the real control center (replay attack), bypassing authentication, stopping and starting the CPU, dumping the device memory, disabling password protection, manipulating the programmable logic, and obtaining Telnet credentials to be able to log in to the PLC. [16]

In 2012, Project Basecamp was started by the cyber security and research firm Digital Bond to demonstrate the insecurity in SCADA field devices such as PLCs and RTUs. Six devices manufactured by General Electric, Schneider Electric, Koyo, Scweitzer Electronics, and Wago were tested for security issues by Digital Bond and volunteer researchers. Many vulnerabilities were found, as well as issues caused by "insecure by design" functionalities, that worked as intended, but could be used to exploit the system.

(22)

Attack methods found by Project Basecamp included forcing the system to stop, crashing the CPU, dumping the device boot code, resetting the device, crashing the device, and writing new firmware to the device. These attacks used vulnerabilities in the CIP (Common Industrial Protocol) communication protocol. Since the protocol is used by more devices models than the ones tested, the vulnerabilities demonstrated by Project Basecamp were widespread.

[5]

In order to receive an internal certificate of security conformity by Siemens, the RTU was penetration tested by a team within the company. The penetration test did not cover all parts of the system. Instead it was focused on stress testing to discover Denial-of-Service (DoS) vulnerabilities, port scanning to find open ports of the device, vulnerability scanning to find easily discovered vulnerabilities using those ports, and protocol fuzzing to see how the device behaves when it receives malformed packets. The toolbox program and the web interface were outside the scope of the test. [17]

Since the CP-8000 RTU hit the market, one vulnerability has been found and reported to Siemens. The vulnerability has the CVE (Common Vulnerabil- ities and Exposures) number CVE-2018-13798, and is a DoS attack against the RTU web server. The vulnerability allows an attacker to send specially crafted network packets to ports 80 or 443 on the RTU to crash the web server, which compromises the availability of the web server. The system needs to be rebooted to restart the web server again after the attack. [18] [19]

Another thesis project has previously been done in which a penetration test of the RTU was performed. This thesis found a DoS vulnerability that could be exploited by attempting to brute-force the login credentials for the web interface. It was also discovered that the checksum files, protecting the web interface source code from manipulation, were not being validated properly. An attacker could simply delete the checksum files, which would allow tampered files to be loaded onto the RTU.

(23)

Chapter 3 Method

The two methodologies used during the thesis were threat modeling and penetration testing. This chapter describes the two phases and how they were conducted.

3.1 Threat modeling

Threat modeling is defined by Shostack as using models to discover security problems. [20] The model is an abstraction of the real system, where the details are excluded to be able to see the bigger picture. Threat modeling is often the first step when penetration testing, and includes gathering information about the system under evaluation, creating a model, and analyzing potential threats in the system. This is important in order to make sure that as much information as possible about the system is obtained before the penetration testing begins. The threats identified during the threat modeling step serve as point- ers to where vulnerabilities could be present in the system, and help guide the subsequent penetration testing.

During the threat modeling phase, the first step was to gather information about the RTU and its assets. A data flow diagram was made to visualize the different assets and how they were connected. The STRIDE methodology was then used to identify threats to the system. A delimitation was done, and several threats were selected for penetration testing.

11

(24)

12 CHAPTER 3. METHOD

3.1.1 STRIDE

STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. STRIDE was de- veloped by Kohnfelder and Garg, and is used as a mnemonic to help identify threats against the system. When using STRIDE to look for threats, what is done is essentially enumerating what could go wrong in the system, guided by the threat categories in the mnemonic. [20] A description of the six threat categories can be found below.

Spoofing

Spoofing is pretending to be something or someone other than yourself. This could involve a website pretending to be Facebook in order to trick a user to log in so they can steal their credentials. Another example is spoofing ones IP address to avoid detection during an attack.

Tampering

Tampering includes modifying something, usually on disk, on a network, or in memory. Examples include modifying files, code, or databases stored on a disk, or adding, modifying, or redirecting packets on a network.

Repudiation

Repudiation is claiming that you did not do or were not responsible for something. This can be done with honest intentions or to deceive. These kinds of threats are associated with the logging system used. If there is no log, or if it can be manipulated by an attacker, repudiation threats can be difficult to dis- pute. Examples of attacks include using another user’s account for something or attacking the logs.

Information disclosure

Information disclosure threats are about letting people see information that they are not actually allowed to. This could include finding interesting information in filenames, temporary files, databases with bad permissions, and reading the data or analyzing traffic in the network.

(25)

CHAPTER 3. METHOD 13

Denial of service

A denial of service (DoS) attack consists of consuming the resource needed to provide service. The most common example of a DoS attack is flooding a web server with a lot of traffic to prevent the web server from handling traffic from real users. Other examples includes filling up a data storage so that nothing new can be stored, or absorbing CPU or memory to prevent a process from running.

Elevation of privilege

Elevation of privilege is allowing someone to do something they are not authorized to. One example of this is allowing a normal user to execute programs as an administrator. Two ways of elevating privilege are getting past authorization checks and corrupting a process.

3.2 Penetration testing

Penetration testing (or pentesting) is commonly used to evaluate the security of an IT system. Pentesters are hired by an organisation and given permission to attack their IT system. The pentester simulates real attacks to try to breach the system under evaluation in order to assess its security. During the pentest, vulnerabilities that could be used by attackers are identified and exploited in order to find out what an attacker might get access to after an successful attack.

The goal of a penetration test is to find the vulnerabilities before an attacker, and recommend how to fix them and what to do to avoid vulnerabilities in the future. [21]

Weidman [21] defines the stages of a penetration test as:

1. Pre-engagement - Discussing the goals and scope of the penetration test before it begins.

2. Information gathering - Searching for information about the system and identifying potential ways to connect to it. s

3. Vulnerability analysis - Trying to discover vulnerabilities in the system.

4. Exploitation - Taking advantage of the vulnerabilities found in the previous stage.

(26)

14 CHAPTER 3. METHOD

5. Post-exploitation - Using the result of exploitation to find interesting information or access to other systems.

6. Reporting - Summarizing the findings and reporting them to the client.

During the thesis work these stages were followed, with some modifications.

There was no client requesting a penetration test for the RTU, so there was no specific goals or delimitation in scope from any external party. Therefore, the pre-engagement stage was skipped. After the threat modeling stage was completed and the threats to be tested were decided, stages 4-6 were done in an iterative manner. For each threat a literature study was done to understand the technical background of the threat and to find out if similar vulnerabilities had been exploited before. After that the exploitation stage begun, and if the exploit was successful, the post-exploitation stage followed. In the reporting stage, the findings were summarized into this thesis report. If any exploits were found, they would be reported to Siemens.

3.3 Lab setup

During the penetration testing a computer running Kali Linux and one running Windows 10 were used. The Windows computer was used as an operator computer, meant to simulate normal use of the web interface. The Kali Linux computer was used as an attacker, simulating a malicious user wanting to exploit the system. The RTU used firmware version 15.10. Both the attacker and the operator computers were connected to RTU using Ethernet cables, since the RTU has two Ethernet ports. The default IP address of the RTU is 172.16.0.3, and the RTU can only be connected to from the 172.16.0.3/24 subnet, so the IP addresses on the Ethernet interfaces on the operator and attacker computer were changed to be in the subnet, as visualized in figure 3.1.

The RTU also functions as a network switch, which means that the attacker computer can connect to the operator computer and vice versa.

(27)

CHAPTER 3. METHOD 15

Figure 3.1: The lab setup used during the penetration testing.

(28)

Chapter 4 Threat model

This chapter presents the threat modeling phase. The results of each step in the threat modeling phase will be detailed, including the information gathering, threat identification, and the threat selection.

4.1 Information gathering

Information about the system under evaluation was mainly gathered from device manuals and brochures publicly available on the Siemens website during the literature study. Additional reconnaissance of the device was also done to gather additional information, such as scanning for open network ports on the device and looking for additional information about the RTU in the firmware and the web interface. In order to fully understand how the device works and to identify potential attack vectors, the system assets were identified and described below.

After reading the available manuals and documents for the RTU, the first step of the reconnaissance consisted of inspecting the firmware files. To aid with this, binwalk was used to extract the files embedded in the firmware. To try to get any information that could be useful from the extracted files, the strings utility was used to output any potentially human-readable stings from the binary files. Two versions of the RTU firmware was inspected, version 15.10 currently running on the RTU, and version 5 that had been used previously. In the output of the earlier version of the firmware, some interesting information was found. Two of the strings found were "Micrium Filesystem"

and "uC/OS-II", which indicates that the RTU is using the real-time operating system (RTOS) Micrium µC/OS-II. A private RSA key was also found in the

16

(29)

CHAPTER 4. THREAT MODEL 17

firmware, along with what appeared to be a header for a shell used by the developers to access the RTU. Tx och Rx frequency were also mentioned, which could mean that the RTU contains a physical UART port on the inside, which is commonly used for debugging during development of embedded devices, and contains two pins called Tx and Rx. The front-end code for the web client was also found in the firmware. In the later firmware version, no useful information could be found other than the front-end code for the web server, which was still present. This indicates that Siemens increased the protection of the firmware in the newer version. Due to not being able to find the the RSA key, shell header, or mentions of the operating system or UART port in the newer version, the key and the shell might not be used in the firmware and getting information from the UART port might not be possible anymore. It is, however, very likely that the same operating system is used, since changing the operating system would be more difficult.

Following the examination of the firmware, the open ports of the RTU were scanned using Nmap. Port scanning was done during the internal penetration test of the RTU done by Siemens described in [17], but since the firmware version currently used on the RTU was released after the penetration test was done, port scanning was done again to verify the results and see if any changes were done. The result of the port scans is shown in Table 4.1, and shows that most of the ports are closed. Port 123/udp is shown as open|filtered, which means that Nmap could not decide whether the port is open, or filtered by a firewall. The service on the port was automatically identified by Nmap.

Finally, the web interface was examined. The web interface is used by an operator to remotely monitor and configure the RTU. A screenshot of the landing page is shown in figure 4.1. In the previous thesis work done it was not possible to log in to the web interface since the password was not known. In the start of this thesis work a firmware update was made, which effectively reset the web interface accounts and passwords to the default ones. This allowed us to choose a new password and log in to the web interface.

After looking through the web interface there were a few things that looked interesting, namely the security logging, user administration page, and the device settings. The device settings were of particular interest, since they allow the user to enable or disable security features, such as encryption of the traffic between the web interface and the RTU, changing the encryption method used, RADIUS authentication, and logging of events on an external SysLog server.

(30)

18 CHAPTER 4. THREAT MODEL

Table 4.1: Port scan results Port State Service Description

80/tcp closed http HTTP

102/tcp closed iso-tsap ISO-TSAP Class 0 protocol

123/udp open ntp NTP

161/tcp closed snmp Simple SNMP 162/tcp closed snmptrap SNMPTRAP 443/tcp open ssl/http HTTPS

500/tcp closed isakmp VPN Key Exchange 514/udp closed syslog SysLog

1812/tcp closed radius RADIUS

2404/udp closed iec-104 IEC 60870-5-104 2404/tcp closed iec-104 IEC 60870-5-104 4500/udp closed nat-t-ike IPsec NAT-Traversal 20000/tcp closed dnp DNP3

Figure 4.1: Screenshot of the SICAM WEB landing page

Disabling encryption of the web traffic caused the system to use the plaintext HTTP protocol instead of the encrypted HTTPS protocol. This opened the HTTP port on the RTU (80/tcp) and closed the HTTPS port (443/tcp).

From the settings it was also possible to enable a debug port on the device.

(31)

After enabling the debug port, the ports of the RTU were scanned again, and a Telnet port (23/tcp) had opened. Connecting to the telnet port produced a login prompt where username and password were required. Since there was no mention of a telnet port or credentials for it in any of the manuals read, it was assumed that the telnet port was only meant to be accessed by the developers of the device. After some manual testing it was found that the username was

’administrator’, but the password was not discovered. An attempt was made to brute-force the password, however this quickly caused the RTU to freeze and not respond to any further requests until restarted.

4.2 Assets

The assets in the system have been divided into three categories; software, communication, and hardware. The software category includes software either running on the RTU, or used to communicate with it. Communication includes the different communication protocols that the RTU uses. Finally, the hardware category includes the hardware ports on the RTU.

4.2.1 Software

The software category includes software used by the operator to communicate with the RTU, such as the web interface and the toolbox program, as well as software running on the RTU, such as the operating system, firmware, and web server. The identified software assets are described in Table 4.2.

4.2.2 Communication

The list of communication assets include all of the different communication protocols that can be used by the RTU. The list includes a lot of different protocols, where many of them are available as options for RTU features, and therefore not all protocols can be used at the same time. Some of the protocols may be used to transmit packages of another protocol. Each asset includes the medium used for communication using the protocol, either LAN/WAN (Lo- cal/Wide Area Network) or serial (RS-232 and RS-485). The identified communication assets are described in Table 4.3 (LAN/WAN) and 4.4 (serial).

(32)

Table 4.2: Software assets

Asset Description

SICAM WEB The web interface used for

communication with and monitoring of the RTU.

Web server The integrated web server in the RTU where the web interface is hosted.

SICAM TOOLBOX II The toolbox program used for communication with and monitoring of the RTU.

Firmware The firmware for the RTU.

Placed on an SD card and inserted in the RTU, or installed remotely using the web

interface of toolbox program.

Currently running version 15.10.

Firewall Used to monitor and control the

incoming network traffic.

SQLite database Stores application data.

SysLog client Sends logging information to a remote SysLog server.

Deactivated by default.

Micrium µC/OS-II The RTOS used on the RTU.

(33)

Table 4.3: LAN/WAN communication assets

Asset Communication

medium

Description

IPsec VPN LAN/WAN Used to secure

communication with the RTU.

RADIUS LAN/WAN Optional authentication

method.

SysLog LAN/WAN Used to communicate with

the remote SysLog server.

HTTP/HTTPS LAN/WAN Communication with the

toolbox program and the web interface. HTTP is used by default.

NTP/SNTP LAN/WAN Time management and time

synchronization

Telnet LAN/WAN Used for debugging by the

developers. Disabled by default.

DNP3 TCP/IP LAN/WAN Can be used for

communicating with substation computers and a central station

IEC 60870-5-104 LAN/WAN Can be used for communicating with substation computers and a central station.

IEC 61850 LAN/WAN Can be used for

communicating with substation computers and a central station.

TFTP LAN/WAN Can be used to

automatically download configuration files.

Disabled by default.

DHCP LAN/WAN Used to obtain an IP address

during automatic configuration.

SNMP LAN/WAN Can be used by an operator

to remotely control and communicate with the RTU.

(34)

Table 4.4: Serial communication assets

Asset Communication

medium

Description

Modbus RTU Serial Can be used for

communicating with external communication modules.

DNP3 serial Serial Can be used for

IEC 60870-5-101 Serial Can be used for

IEC 60870-5-103 Serial Can be used for

4.2.3 Hardware

The hardware assets in the RTU include the different hardware ports available.

Information indicating the presence of the UART port was found during the information gathering stage described above, and its existence has not been fully confirmed. For threat modeling purposes, it is included in the list of assets. The hardware assets are described in Table 4.5.

4.2.4 Data flow diagram

To get a better understanding on how all of the assets were connected, a data flow diagram was created. The data flow diagram helps put the identified assets into context, and helps when identifying threats in the system. The developed data flow diagram is shown in figure 4.2. Apart from the previously identified assets, the diagram also includes a trust boundary around the assets that are present in the RTU. Trust boundaries are used to visualize who controls the different assets in the diagram. Examples of where trust boundaries are commonly used includes separating network interfaces, different physical devices, virtual machines, organizational boundaries, and anywhere else where

(35)

Table 4.5: Hardware assets

Asset Description

2x Ethernet ports Used for LAN/WAN

connection.

RS-485 port Used for multi-point traffic

RS-232 port Used for for multi-point,

point-to-point or dial-up traffic according to IEC.

UART Located inside the RTU (most

likely). Often used to get debug information during

development

SD-card slot Used to insert firmware and data.

differences in privilege exists. [20]

4.3 Identifying threats

When all of the system assets had been identified, it was time to identify potential threats to the system. The STRIDE methodology described in 3.1.1 was used to aid with the threat identification process. In addition to researching threats and evaluating whether they would be applicable to the RTU or not, vulnerability scans were performed to try to automatically detect known vulnerabilities present in the system. Three different scanners were used; Arachni, OpenVAS, and TestSSL. Arachni and OpenVAS scans for a wide range of vulnerabilities, while TestSSL only scans for vulnerabilities in the HTTP/HTTPS connection. After the scans had been completed, Arachni had not discovered any vulnerabilities. OpenVAS had discovered two vulnerabilities in the TL- S/SSL encryption used in the HTTPS communication, and indicated that the RTU might be vulnerable to the SWEET32 and POODLE attacks, which can leak sensitive data in the encrypted communication between the operator and the web server on the RTU. TestSSL gave the same results as OpenVAS, as well as alerting that the server certificate used to prove that the server is the real RTU was self-signed. Both OpenVAS and TestSSL reported that the SS- L/TLS versions supported for encrypting the HTTPS traffic were TLS v1.2, v1.1, v1.0, and SSL v3.

(36)

Figure 4.2: Data Flow Diagram

(37)

The identified threats to the RTU are listed below divided into the six STRIDE categories.

Spoofing

• Brute force/guess credentials to log in as someone else.

• Spoof the NTP server to send the wrong time to the RTU.

• Spoof the TFTP server the RTU gets the configuration file from.

• Replay attacks to spoof the control center.

• Spoof the RTU to send fake events to the SysLog server in order hide malicious activity.

• Spoof the TFTP server to do make the RTU download a malicious configuration file.

• Exploit the fact that the server certificate is self-signed to spoof the web interface login page to harvest operator credentials.

Tampering

• Tamper with the control packets to make the device do the wrong things, deactivate settings, etc.

• Tamper with the firmware to inject malicious code into the code running on the RTU or the web interface.

• Exploit XSS vulnerabilities on the website allowing an attacker to insert their own code in the web interface.

• Tamper with the RADIUS authentication to authorize logins.

Repudiation

• Attck the logging functionality to confuse the logs, or the code that reads the logs.

(38)

Information disclosure

• Dissect the firmware to find sensitive information about the code and the system.

• Use the SWEET32 or POODLE attacks to gather information by analyzing the network traffic.

• Exploit a vulnerability in the operating system to read sensitive data.

• Connect to the UART port to access debug information.

• Login to the Telnet port used for debugging to gain access to the underlying RTU system and information about it.

Denial of service

• Open lots of connections to consume network resources.

• Conduct a NTP amplification attack.

• Perform a factory reset of the device to delete all SD-card data, logs, and configurations (parameter, user management, users, passwords, keys, certificates).

• Physically sabotage the device.

Elevation of privilege

• Elevate privilege through buggy authorization checks on the web interface and the toolbox program.

• Elevate privilege by modifying the firmware to do other things than what the authorized user intends.

4.3.1 Selecting threats

After enumerating the possible threats, some were chosen to be explored in detail. When conducting a thorough penetration test, as many threats as possible, if not all, should be investigated. However, due to the time constraints of the thesis some delimitations had to be made.

Attacking the serial communication over RS-232 and RS-485 was left out

(39)

of the scope early, since no equipment to test with was available. The most promising ways to exploit the system seemed to be attacking the communication on the open network ports, between the operator and the RTU, the web interface or the toolbox program, and the firmware. Due to not having access to the toolbox program, it was left out of the scope of the thesis. The initial look into the earlier version firmware had revealed some interesting information, and looking further and reverse engineering the firmware could have led to finding more, and potentially being able to change the code for the RTU. While promising, this requires a lot of time, and is made difficult by the fact that very little information exists about the operating system used, and no previous efforts to reverse engineer it or programs written for it could be found. Because of the time constraints, reverse engineering and modifying the firmware and trying to find vulnerabilities in the operating system were also left outside the scope of the thesis.

Thus, the attack vectors chosen to be investigated were the web interface and the communication on the open ports: HTTPS, and NTP. The telnet port, while open, required a password which was unknown, and brute-forcing it proved to not be a viable option. Therefore the telnet port was not chosen to be tested along with the other ports.

(40)

Chapter 5 Theory

After delimitations were made, a literature study was done on the theory be- hind the chosen attack vectors, and the attacks that exist for them. This chapter describes this background theory.

For the web hacking the choice was made to focus on the attacks in the OWASP Top 10, since they are the current most critical security risks commonly found in web applications.

5.1 Network Communication

This section will focus on the protocols used on the open ports, a.k.a HTTP/HTTPS (communication with the web server), and NTP.

5.1.1 Network Architecture

Computer networks use lots a wide variety of different protocols for communication. To make things easier and provide structure, network protocols have been organized into different layers that provide different services, where every network protocol belongs to one of these layers. A protocol layer can be implemented in software, hardware, or a combination of the two.

When together, the different layers are called the protocol stack. The Internet protocol (IP) stack consists of five layers: the physical, link, network, transport, and application layers. The IP stack is visualized in Figure 5.1. A layer can be implemented in software, hardware, or a mix of the two. [22]

28

(41)

CHAPTER 5. THEORY 29

Figure 5.1: Visualization of the layers in the Internet protocol stack Application layer

Network applications are the reason network communication is needed. This is where protocols such as HTTP/S, FTP, and SMTP reside, which are used by web browsers, file sharing applications, and mail clients. The application developers rely on the layers below for reliable transport and finding the correct destination. [22]

Transport layer

The transport layer is used to encapsulate the application layer protocols and transport them between applications on different hosts. The most commonly used transport layer protocols are TCP and UDP, where TCP provides reliable and connection-oriented communication, whereas UDP is a simpler, unreli- able, connectionless protocol. [22]

Network layer

The network layer is responsible for moving the network traffic between hosts.

The Internet Protocol (IP) is used to provide hosts with unique addresses to enable the communication. The layer also includes different routing protocols responsible for determining the route between the source and end hosts for the network traffic. [22]

(42)

30 CHAPTER 5. THEORY

Link layer

To move the traffic between nodes in the route determined by the network-layer routing protocol, the services of the link layer are used. Examples of link layer protocols commonly used are WiFi and Ethernet. [22]

Physical layer

The physical layer is responsible for transporting the individual bits of the traffic between nodes. This is done using e.g. copper wire cables, fiber optics, or radio waves. [22]

5.1.2 NTP

NTP (Network time protocol) is an application-layer protocol that is used to synchronize system clocks time servers and clients. There are a number of primary time servers that are synchronized to reference clocks traceable to UTC (Coordinated Universal Time). Secondary time servers have one or more upstream primary time servers, and one or more downstream time servers or clients. A client synchronizes their time to one or more of the upstream time servers, primary or secondary. [23]

5.1.3 HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the primary application-layer protocol used by the web. Clients and servers on the internet communicate with each other by exchanging HTTP messages. HTTP defines how clients request websites from servers, and how the servers transfer the websites to the clients.

When a user requests a website, an HTTP request is sent by the browser to the server. The server then responds with an HTTP message containing the requested objects, if available. HTTP uses TCP as the underlying transport protocol, providing reliable data transfer.

A TCP connection does not last that long, and sometimes the web server might want to identify different users, both to serve specific content and to restrict user access. To provide this functionality, HTTP uses cookies, which allows sites to identify users. When a user accesses a web site using cookies for the first time, a cookie is created. The cookie is a unique value meant to identify the user, and is sent back to the user along with the requested web page. The user’s browser then stores the cookie locally, and for each request sent to the

(43)

web server in the future the cookie value is included in order to identify the user sending the request. This way a user can stay logged in to a web page and not have to enter their credentials every time they visit the web page. [22]

A similar way is to use session IDs, where a unique ID is created when a user visits the web site, and is then included in the requests sent. A session ID is not stored in the users browser, and will have a shorter life span. Sessions are usually short-lived and expire after a specified period of inactivity (can be minutes or hours), whereas cookies can stay valid for a longer time.

HTTP messages are sent in plain-text, which makes it easy for an attacker eavesdropping on the traffic to see exactly what is being sent and received, including login credentials and other sensitive information. In order to mitigate this, HTTPS is used. HTTPS traffic uses SSL (Secure Sockets Layer) or TLS (Transport Layer Security) to encrypt the traffic, which prevents the information from being leaked. SSL and TLS are used to secure TCP connections in general, and can be used to protect other application-layer protocols. TLS is a modified version of SSL version 3, and has been standardized by the Internet Engineering Task Force (IETF). [22] The latest version of TLS in use is currently 1.3. [24]

SSL version 3 was released in 1996, and has since then been the subject of many attacks and cannot be seen as secure. Despite being replaced by TLS in 1999, many web sites still supported SSLv3. It was formally deprecated in 2015 by the IETF. [25] As described in section 4.3, the RTU web server still supports SSLv3.

5.1.4 ARP

ARP (Address Resolution Protocol) is a link-layer protocol used to translate between IP and MAC addresses. To send a packet from one host to another in a subnet, the sending host needs both the IP and MAC address of the recipient.

To determine the MAC address of the recipient, ARP is used.

To find the recipients MAC address, the sender will first check its ARP table, which contains entries with mappings from IP addresses to MAC addresses.

Each entry expires after a set amount of time and is then removed from the ARP table. If there is no entry for the recipient’s IP address in the ARP table, the sender will broadcast an ARP packet with a query to all the hosts on the

(44)

subnet asking for the MAC address of the host with the IP address of the recipient. Each host on the subnet will compare the IP in the ARP packet with their own, and the matching host will respond. The sender will then receive the missing MAC address, update its ARP table with the new IP - MAC map- ping, and finally send the packet to the recipient. This process is visualized in figure 5.2

Figure 5.2: Finding a target’s MAC address using ARP

ARP only resolves IP addresses for hosts and router interfaces in the same subnet as the sending host. Traffic over different subnets (like the internet) works in a similar way, except that the traffic gets sent from router to router until it reaches the intended recipient. [22]

5.2 Network Attacks

In modern systems a lot of different protocols are used to provide functionality. The disadvantage with this is that using many communication protocols also introduce many potential weaknesses that can be exploited by an attacker to get sensitive information from, or even gain entry to the system.

Some network attacks applicable to the Protocols used by the RTU are described below.

(45)

5.2.1 Man-in-the-Middle

A Man-in-the-Middle (MitM) attack is performed by an attacker in order to be able to intercept and redirect traffic sent between two systems, before passing it on to the correct destination. To perform a MitM attack and intercept the traffic, the attacker has to place themselves between the two systems, and trick the victim to send the traffic intended to the other system to the attacker instead.

One method to trick the victim is to use ARP spoofing.

ARP Spoofing

ARP spoofing (also known as ARP cache poisoning) is a method that can be used to perform a MitM attack by exploiting the ARP protocol. As described in section 5.1.4, an ARP request is sent out when a host wants to send something to another host in the subnet to find its MAC address. The spoofing is done by an attacker replying to the ARP request with their MAC address before the intended recipient does, tricking the sending host into thinking that the attacker is the intended recipient. This information then gets logged into the sending hosts ARP table, which has now been poisoned with false information. The ARP spoofing process is visualized in figure 5.3.

Figure 5.3: ARP Spoofing

Since the sending host thinks that the attacker is the intended recipient, all messages it wants to send to the recipient is sent to the attacker, who can then inspect all of the incoming traffic from the sender. If the messages sent are

(46)

in plain-text, such as when using HTTP or FTP, the attacker can obtain login credentials and other sensitive information.

To make sure that the traffic passing through the attacker reaches the intended recipient, the attacker needs to enable IP-forwarding on their computer. If the traffic is not forwarded, a DoS situation is created, where we have prevented the sender from communicating with the recipient. [21]

POODLE

The POODLE (Padding Oracle On Downgraded Legacy Encryption) attack on SSLv3 was discovered by security researchers at Google and was disclosed in October 2014. The vulnerability can allow an attacker to steal sensitive information, such as cookies, session IDs, and similar tokens, from HTTP requests by using a MitM attack. While the use of SSLv3 mostly has been replaced with TLS, there are still servers that support SSLv3 for backwards compat- ibility. Even if both the server and client support TLS, if they also support SSLv3 the connection can be downgraded to use the insecure SSLv3 instead.

[26]

The POODLE attack targets the block cipher encryption in the cipher-block chaining (CBC) mode in SSLv3. The CBC encryption is done in blocks (e.g.

16 bytes in AES encryption) and if the text to be encrypted does not fill whole blocks, the text needs to be padded. One method of padding is the PKCS#7, which dictates that if one byte of padding is needed, a byte with the hexadecimal value 0x01 is appended to the text. If two bytes of padding are needed, two bytes with the value 0x02 are appended, and so on. If no padding is needed, a block with 16 bytes with the hexadecimal value 0x10 (16 in decimal) is added after the last block. [27] One problem with the CBC encryption in SSLv3 is that it is not possible to verify that the padding has not been tampered with when decrypting, since it is not covered by the message authentication code that detects if the message content has been modified in transit. [26]

During CBC encryption of blocks the encrypted value of the previous block is used when encrypting the current block. The ciphertext (encrypted value) of block N − 1 is XORed with block N before block N is encrypted with some key. The first block in the chain is XORed with a random initialization vector (IV) before being encrypted. The encryption procedure is visualized in figure 5.4. The CBC decryption follows the same procedure, but reversed. The

(47)

ciphertext of block N is first decrypted, and then XORed with the ciphertext of block N − 1 to reveal the plaintext. The plaintext of block N − 1 is not needed to decrypt block N . The IV is used to decrypt the first block. [28] The decryption procedure is shown in figure 5.5.

Figure 5.4: CBC encryption

Figure 5.5: CBC decryption

To conduct the POODLE attack, an oracle is needed. The oracle will leak information about whether the padding in a block is valid or not. An example of an oracle could be a server which gives an error if the padding is incorrect, and no error if it is correct.

The mathematical formula for the CBC decryption is Pi = D_k(C_i) ⊕ C_i−1,

(48)

where C0 = IV . Since each plaintext block Dk(C_i) is XORed with the previous ciphertext block Cⁱ⁻¹, modifying a single byte in C¹ will result in a corresponding change in the plaintext block P². An attacker has two blocks C₁ and C2 and wants to find the plaintext P2 of block C2. The attacker alters the last byte of C1, creating C1⁰, and sends (IV, C1⁰, C₂) to the oracle. The oracle will respond with whether the padding of the last decrypted block, P2⁰, was correct (equals 0x01). If the padding is correct, the attacker will know that the last byte of Dk(C₂) ⊕ C₁⁰ is 0x01, which in turn means that Dk(C₂) = C₁⁰⊕ 0x01. If the padding is incorrect, the attacker can change the modified last byte of C1⁰ to the next possible value and try again until the padding is valid.

Thus at most 256 attempts are required per byte to find the correct value.

After determining the last byte of P2, the same technique can be used can be used to determine the second-to-last byte of P². The attacker sets the last byte of P² to 0x02 by modifying the last byte of C¹ to D^k(C₂)⊕ 0x02. The same approach that is described above is then used, modifying the second-to- last byte until the oracle responds that the padding is correct, which now is 0x02, 0x02. This can be iterated until all of the bytes in the block has been revealed. [29]

The only ways to properly mitigate this attack is to disable the use of SSLv3 in the client or server, or disallow connections using SSLv3 when both client and server supports TLS. [26] As described in section 5.1.3, SSLv3 was formally deprecated in 2015, and Firefox and Chrome disabled the use of SSLv3 by default shortly after the POODLE attack was disclosed in 2014 [30] [31]. De- spite this, there are most likely computers out there that has not been updated since 2014 that are still vulnerable.

5.2.2 Replay Attacks

An attacker intercepts traffic and redirects or resends it to make the receiver do what the attacker wants. This can be done even if the message is encrypted.

The attacker just needs to resend the message for the attack to be successful.

[32] An example could be that a user wants to send someone via their online bank. The attacker is listening to the traffic and identifies the message from the user to send the money. The attacker can save the message, and later send it again, making the user send money again, reducing the amount in their bank account. The message looks legitimate, since it it a legitimate message that was sent by the user. The attacker could also try to modify the packet, making

(49)

the user send the money to the attacker.

HTTPS is not vulnerable to replay attacks. Each HTTPS packet sent has a sequence number indicating the order of the packets. This sequence number is used when calculating the packet checksum. If a packet is captured by an attacker and replayed, the receiving host will notice that the packet was sent out of order, discard it, and drop the connection. [22]

5.2.3 Denial of Service

A Denial of Service (DoS) attack occurs when system resources are being consumed by someone or something, which results in the system or network performance being slowed down or stopped completely. DoS attacks cause problems for both operating systems as well as networks, due to the fact that if the system is shut off, all the storage is filled, or too many processes are created, it will not be possible to use and work with the system. One way to perform a DoS attack on a network is too flood the victim with messages by sending a lot of requests to it. The victim’s system resources will be overloaded, meaning that it will not be able to handle new requests by legitimate users, and may crash. A Distributed Denial of Service (DDoS) attack is performed in a similar way, where the difference is that the malicious traffic originates from many sources at once to make blocking the DoS attack more difficult. [33]

NTP Amplification

An NTP amplification attack is a type of DoS attack that uses a NTP server to overwhelm a system with traffic. The NTP service supports monitoring functionality that allows server administrators to query the server for traffic counts of connected clients. This is done by querying the NTP server using the mon- list command, which replies with a list of the 600 latest IP-addresses that connected to the NTP server. The attack is performed by sending the mon- list request to a vulnerable NTP server, with the source address spoofed to be the victim’s IP-address, which causes the response to be sent to the victim.

Since the response is often considerably larger in size than the request, the volume of traffic sent to the victim is amplified. Since the response received is valid data coming from a legitimate NTP server, it can be difficult to block.

The vulnerability can mostly be found in older NTP servers, where the mon- list is enabled by default. The functionality has been disabled since version 4.2.7 of NTP. [34]

(50)

5.3 Web hacking

These days, almost everything in people’s day-to-day lives can be done online using web applications. We trust the web application with all kinds of sensitive and vulnerable information and data, such as bank details, login credentials, and personal information. Often the web servers are just one part in a large system used for the various services. This makes web applications an attrac- tive target for attackers looking to gain access to the sensitive information, or gain access to the underlying system. There are many ways to exploit a web application if it has not been secured properly, that ranges from insecure cod- ing practices allowing an attacker to inject code to gain access to databases or executing code in other users’ browsers, or broken access control and authentication allowing an attacker to perform actions they do not have authentication to do. [35]

During the penetration testing of the web interface, the choice was made to focus on the vulnerabilities listed in the OWASP Top 10.

5.3.1 OWASP Top 10

The Open Web Application Security Project (OWASP) is a nonprofit founda- tion that started in 2001 and works to improve the security of software. [36]

One project maintained by OWASP is the OWASP Top 10, which is a regularly updated list that represents a broad consensus of the ten most critical security risks in web applications. The primary aim of the list is to educate developers, architects, managers, organizations, etc., about the most common web application vulnerabilities. The current version is OWASP Top Ten 2017, and list the following vulnerabilities: [37]

1. Injection (SQL, NoSQL, OS, and LDAP) 2. Broken Authentication

3. Sensitive Data Exposure 4. XML External Entities 5. Broken Access Control 6. Security Misconfiguration 7. Cross-Site Scripting (XSS)

Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

EMMA GOOD

Security Analysis of a Siemens SICAM CMIC Remote Terminal Unit

EMMA GOOD

Abstract

Sammanfattning

List of Acronyms

Contents

Chapter 1 Introduction

1.1 Problem statement

1.2 Research question

1.3 Methods

1.4 Delimitations

1.5 Outline

Chapter 2 Background

2.1 Remote Terminal Units

2.1.1 Security considerations

2.2 SICAM CMIC RTU

2.2.1 Security

2.3 Related works

Chapter 3 Method

3.1 Threat modeling

3.1.1 STRIDE

3.2 Penetration testing

3.3 Lab setup

Chapter 4

Threat model

4.1 Information gathering

4.2 Assets

4.2.1 Software

4.2.2 Communication

4.2.3 Hardware

4.2.4 Data flow diagram

4.3 Identifying threats

4.3.1 Selecting threats

Chapter 5 Theory

5.1 Network Communication

5.1.1 Network Architecture

5.1.2 NTP

5.1.3 HTTP and HTTPS

5.1.4 ARP

5.2 Network Attacks

5.2.1 Man-in-the-Middle

5.2.2 Replay Attacks

5.2.3 Denial of Service

5.3 Web hacking

5.3.1 OWASP Top 10