Enhancing
Network Scanning
For
Discovering Vulnerabilities
(ENSDV)
by
Raymond Cordova MEIA
University of
Colorado at Colorado Springs, Colorado, 2010
A Thesis
Submitted to the Faculty of
the
Graduate School
University of Colorado at Colorado Springs
Partial Fulfillment of the Requirements
for the
d
egree of
Master of Engineering
in Information Assurance
Department of Computer Science
20
10
ii
T
hesis for the Master of
Engineering
D
egree
in
Information Assurance
by
Raymond Cordova
A
pproved for the
Department of Computer Science
by
_______________________________________________________
Advisor: Dr. C. Edward Chow
_______________________________________________________
Dr. Jugal K. Kalita
_______________________________________________________
Dr
. Rory Lewis
_____________________
Date
iii
ENSDV
Enhance
Network Scanning for
Discovering Vulnerabilities
Master of Engineering,
Information Assurance
Thesis directed by Associate
Dean
Professor C. Edward Chow
Department of Computer Science
iv
Enhance
Network Scanning for
Discovering Vulnerabilities
Master of Engineering,
Information Assurance
Thesis D
irected by Associate
Dean
Professor C. Edward Chow
Department of Computer Science
Abstract
With the advent of the 911 terrorist attack and the subsequent identification of the
vulnerabilities of our most critical systems that include the power grid, directives from
government entities such as Homeland Security, has coined the term “Smart Grid” t
o
describe Industrial Control Systems (ICS) as a
power grid of the near future
;
an
intelligent, self
-
healing, real
-
time system
. The ongoing effort to develop
secure
communications products and technologies specifically designed to operate reliably in
harsh
environments around the world must be used for mission critical applications
.
The methodology and prevention of attacks to ICS networks is by far one of the most
important projects since the creation of the Internet. It should be noted that the
number of
vulnerabilities
that
can be exploited and the critical nature of an exploit is
much more than that of Internet and computer based vulnerabilities.
With this in
v
mind, enhanced network scanning for discovering vulnerabilities becomes an
important research
f
ocus for this master thesis project
.
Our research results
show that
the Nessus vulnerability and compliance check scanner can be enhance
d
to discover
network vulnerabilities.
Many
vulnerabilities require
the
development of plug
-
ins
written specifically
to
address issues not addressed by the standard set of subscription
plug
-
ins.
We demonstrated the process of d
eveloping and creating n
ew
plug
-
ins
for
enhancing
the Nessus scanner to discover vulnerabilities and check for compliance of
policies.
We applied th
e Nessus system with the enhanced plug
-
ins to scan the
vulnerabilities in the subnets of a research and education network, including both
the
credential and non
-
credential based scans
, and
presented the performance analysis
results
.
The lessons learnt and
future directions are also included.
vi
Acknowledgements
I would like to take the opportunity to sincerely thank Dr, Edward Chow for the
support, his tireless efforts,
the valuable time he spends in consultation, the
encouragement he has provided, and the direction to guide me through the challenging
coursework at UCCS. This is my opportunity to thank Dr. Chow, being that he does
so much for others, generously giving hi
s time and providing help and motivation. I
truly appreciate Dr. Chow for the person that he is.
I would a
lso
like to
thank Renaud Deraison from Tenable Nessus for providing the
Pro
fessional
Feed version of the Nessus scanner for the experiments and researc
h
.
Without his contribution, this research would not have been possible.
vii
Table of Contents
Abstract
iv
Acknowledgements
vi
Table of Contents
vii
List of Figures
viii
List of Scripts
x
Tables
x
Appendices
xi
Chapter
1
Introduction
Industrial Control Systems Recommended Guidelines,
Standards and Regulations in Emerging Technology
1
Chapter 2
Emerging Technology
5
2.1
Wireless Comes of Age
9
2.2
Vulnerabilities
10
Chapter 3
Nessus Scanning
13
3.1 Bandolier Related Work
14
3.2 Compliance Checks
14
3.3 Compliance Checks Versus Vulnerability Scan
15
3.4
Development Approach
16
3.5
Extending Bandolier with Nessus Credentialed Scanning
21
viii
3.6 Customize Policies
23
3.7 Nessus Scan Performance Metrics
31
Chapter 4
Lessons Learned
41
4.1
SCADA Access
41
4.2
Meter and Development Kit Procurement
41
4.3
Nessus Scanner
43
4.4
Digital Bond Bandolier Project Compliance
Check Plug
-
ins
45
4.5
Nessus Attack Scripting Language
(NASL)
46
4.6
VMware
47
Chapter 5
Future Direction
49
5.1 Texas Instruments Development Kits
49
5.2 Automatically Patching Failed Compliance Checks
49
5.3 Shared Plug
-
ins
50
5.4 OS Extensions
50
5.5 System Alert for
Detecting Plug
-
in Removal
50
Chapter 6
Conclusion
53
References
57
ix
List of Figures
Figure 2
-
1.
ICS Security
7
Figure 2.2
Emerging Technology Physical Challenges
7
Figure 2.3
Smart Metering
Scope
8
Figure 2.3
Wired and Wireless Options
8
Figure 3.
1
Prototype Layout
31
Figure 3.2
Nessus Scan Performance Times on Prototype
33
Figure 3.3
Nessus Non
-
credential Scan Performance Times on
ISSG
Lab
36
Figure
3.4
Nessus Non
-
Credentialed Scan on ISSG
Lab
37
Figure 3.5
Ness
us Credentialed Scan on ISSG Lab
38
Figure 4.1
Successful Nessus Database Rebuild and Re
-
index
45
Figure B.1
Itron OpenWay® Solution
63
Figure B.2
CC2530
ZDK Development Kit Cost
67
Figure
C
.1
Windows Nessus Download Files
85
Figure
C
.2
Windows Nessus Welcome Screen
84
Figure
C
.3
Windows Nessus License Agreement
84
Figure
C
.4
Windows Nessus Destination Folder
85
Figure
C
.5
Windows Nessus Setup Type
85
Figure
C
.6
Windows Nessus Install Dialog
86
Figure
C
.7
Windows Nessus Completion Dialog
86
x
Figure
C
.8
Windows Server Manager Configuration
103
Figure
C
.9
Activated Windows Server Manager
Dialog
105
Figure
C
.10
Nessus User Management Dialog
106
Figure
C
.11
Nessus Add/Edit User Dialog
107
Figure
C
.12
Nessus Client Login User Dialog
108
Figure
C
.13
Configuration Screen for Credentials
110
Figure
C
.14
Policy
Compliance Plug
-
ins
111
Figure
C
.15.
Example plug
-
in Selection of Operating System
and
Application Security Scans
112
Figure C
.16
Customize Policy Edit
113
Figure
C
.17
Report Example of the iepeers_dll_0day.nasl
plug
-
in and
Windows Compliance Checks on an
un
-
patched XP
virtual machine
114
Figure
C.17.
Report Example of the SSH Remote Root Login
115
Figure C.17.1
Report Example of the SSH Remote Root Login
Compliance Check on a Fedora Core 12 virtual
machine
115
Figure
C
.18
Nessus User Tab
117
Figure
C
.19
Nessus Policy Tab
118
Figure
C
.20
Nessus Scan Tab
119
Figure
C
.21
Nessus
Report Tab
120
xi
List of
Scripts
Script 3.1
XP “iepeers.dll” 0
-
摡y⁖畬湥牡扩b楴y pc物灴
73
Script 3.2
XP USB Storage Devices Disabled Compliance
Check Audit Script
78
Script 3.3
XP CDRO
M Auto
-
play Disabled Compliance
Check Audit
Script
79
Script 3.4
Fedora 12 SSH Remo
te Root Login Disabled
Compliance
Check Audit Script
80
Tables
Table 1.
Prototype Nessus Scan Time
32
Table 2.
ISSG Nessus Scan
34
Appendices
Appendix A
A.1 Subject
Descriptor
s
60
Appendix B
B.1
Selected Vendor Smart Meters
and Protocols
61
B.1.1 Itron Open Way
61
B.1.2
Texas
Instruments Smart Meters with
Secure
Pre
-
P
ayment
63
B.1.3
Texas Instruments Smart Meters
65
B.1.4.
System
-
on
-
Chip Solutions
65
B.1.5
Standard
-
Based Networks
66
xii
B.1.6
Proprietary Networks
66
B.1.7
Development Platforms
67
B.1.8
MBUS3 Firmware
68
Appendix C
C.1 Nessus Quick Reference Installation and
Upgrade
Guide
7
0
C.1.1
Nessus Background
7
0
C.1.2
OS Support
7
2
C.1.3
Prerequisites
7
3
C.1.4
Installation
7
4
C.2
Upgrading Unix/Linux
87
C.3
Upgrading Windows
10
0
C.4 Nessus Directory Configuration
100
C.5 Nessus Server Manager and Client Interface
102
C.6 Changing Default Nessus Port
103
C.7 Registering the Nessus Installation
104
C.8 Adding User Accounts
104
C.9 Host
-
Based Firewalls
108
C.10 Other Operating System Configuration
109
C.11 Policy
Compliance Plug
-
ins
110
C.12 Patch Auditing
111
C.13 Netstat Port Scanner
112
xiii
C.14 Reporting
113
C.15 Nessus Scanner Use
116
C.16
Nessus User Configuration Tab
117
C.17 Nessus Policy Configuration Tab
118
C.18 Nessus Scan Tab
119
C.19 Nessus Report Tab
120
xiv
This page intentionally left blank.
1
1
Chapter 1
Introduction
Industrial Control System
Recommended Guidelines,
Standards and Regulations in the
Emerging Technology
The Information Technology Laboratory (ITL) at the National Institute of
Standards and Technology (NIST) promotes the U.S. economy and public welfare
and provides technical leadership for the nation’s measurement and standards
infrastructure.
Specific
requ
irements and methodologies for information system
categorization are described in Technology (NIST) FIPS 199. The requirements for
addressing minimum security controls for a system are described in NIST SP 800
-
53
(
Recommended Security Controls for Federal
Information Systems
)
and NIST FIPS
200
(Minimum Security Requirements for Federal Information and Information
System).
ITL responsibilities include the development of technical, physical,
2
2
administrative, and management standards and guidelines for the cos
t
-
effective
security and privacy of sensitive unclassified information in the nation’s computer
systems that have emerged to provide control of industrial control networks.
In the emerging stages of development, inexpensive Internet Protocol (IP)
devices
began replacing proprietary isolated systems running proprietary control
protocols using specialized hardware and software. The possibility of cyber security
vulnerabilities and incidents increased as ICS began adopting Internet solutions to
promote corpor
ate business systems connectivity an
d remote access capabilities [15
].
A different approach was needed to address the issues [1
4
]. These new design
implementations using industry standard computers, operating systems (OS) and
network protocols began to res
emble Internet systems. As mentioned earlier, the ITL
standards set forth in the NIST 800 series documents is a challenging and daunting
task
[9]
. This task is coupled with securing Internet access to ICS systems, isolating
the ICS, and providing a secure
, safe, reliable control system. It is interesting to note
how emerging technologies have lowered the infrastructure costs and use existing
physical entities and infrastructure.
As these AMI/AMR solutions are implemented, there must be a controlled
effort
to ensure security is built in so as not to produce results similar to the problems
encountered by the staggering growth of the Internet which produced undesirable
circumstances in which services were the most important factor.
3
3
The development of a Smart
Grid has focused on Security, being that the
new ICS will inherently have all of the vulnerabilities of Internet and computer based
systems. It will be critical for the smart grids to provide confidentiality, integrity and
availability to ensure the criti
cal infrastructure is not compromised in the event of a
catastrophic failure, cyber event or and unforeseen disaster. Authoritative entities
have produced the NIST 800
-
82 Guide to Industrial Control Systems Security (ICS)
[11 [1
5
] in an effort to provide g
uidance to establish secure industrial control systems
(ICS). The methodology and prevention of attacks to ICS networks is by far one of
the most important projects since the creation of the Internet. It should be noted that
the number of vulnerabilities t
hat can be exploited and the critical nature of an exploit
is much more than Internet and computer based vulnerabilities. Instead, not only
does the development of
Supervisory Control
a
nd Data Acquisition
(SCADA)
systems, ICS or Smart Grids take conventio
nal computer based vulnerabilities into
account, but also new and ambiguous vulnerabilities that are being identified are
unique to the critical smart grid industry. Policies and processes exist with new
vulnerabilities being discovered daily and new tool
s, code, procedures and processes
are generated daily address any deficiency in the development of the smart grid
systems.
Although
security can be built into the
critical
systems
, there are still
vulnerabilities discovered after release into production. The Nessus scanning tool can
greatly contribute to ease the task to discover vulnerabilities and check for policy
compliance
of
critical infrastructure components.
The tool functio
ns with a
4
4
customizable policy to define specific
scans that
can target unique configurations
and systems to meet pre
-
defined standards. The ability to develop fine granular plug
-
in scripts provides the scalability, flexibility and robustness to use scripts
in a
systematic methodology to build a collection of simple scripts that can become a
complex script scan task. This is accomplished through the use of dependencies on
the results of a previously run script or
scripts
.
Each script is a simple building blo
ck
that can ultimately become a foundation for a complex inter
-
dependent scan process
.
5
5
Chapter 2
Emerging Technology
There have been many problems associated with the rapid growth of the Internet.
The vulnerabilities associated with the Internet are well
known problems that
introduce a critical security problem to ICS. Many of the solutions to prevent these
vulnerabilities have been no more than a band
-
aid fix that are not at all ideal in their
implementation. Many of the solutions to the problems have onl
y introduced other
problems that introduce other security risks. With all the problems that currently
effect the IP based technology, it becomes imperative to follow the directives set forth
by the NIST 800 series documents. It becomes a monumental task to
secure an
already vulnerable IP
-
based system and to secure emerging technology. Emerging
technology solutions have inherent vulnerabilities in their own implementations. It
seems reasonable to expect emerging technologies will require all the traditional
tasks
of security updates, patches, updates and upgrades as will as providing System
Development Life Cycle activity of the emerging technologies implemented to
provide solutions to ICS. As the emerging technologies are implemented, care must
be given to
the implementation and infrastructure with a focus on three components;
availability, integrity, and confidentiality of the ICS
. This focus is
critical and must be
strictly adhered to in order to provide a safe and secure system.
The implementation of secu
rity in the leaf products of the various AMI/AMR
devices becomes a major task of providing a reliable and safe solution of gathering
6
6
information from millions of end points. As is the case with any emerging
technology, new solutions have inherent vulnerabi
lities, and the Advanced Metering
Infrastructure/Advanced Metering Readers (AMI/AMR) is not an exception
.
These
smart meters
must be
considered as a device that can be used to gain access to the
larger infrastructure, the SCADA power grid. Therefore, every
precaution must be
taken to protect the meters since these smart meters are a potential gateway to the
more critical SCADA power grid infrastructure.
Several problems are associated with the securing smart meters. These meters must
update usage statistics
for, which include but are not limited to several resources,
such as gas, water, and electricity. It is critical that every effort to maintain security
for these devices becomes a normal practice in order to provide a safe and secure
system.
The followin
g figures illustrate the infrastructure, physical challenges, scope,
and wired and wireless solutions:
See Figure 2.1 for an illustration of securing a typical ICS [
2
].
Figure 2.2 shows the challenge of physical security [
2
].
See Figure 2.3 for the scope
o
f the smart metering system [16
].
Figure 2.4 shows a typical ICS infrastructure with wired and wireless
solutions
[16]
.
7
7
Securing Control Networks
5/29/2009
Smart Grid Education Workshop / Chow
10
Figure 2.
1
ICS Security
Figure 2.
2 Emerging Technology Physical Challenges
Slides on this page a
dapted from Juniper Network
White Paper on ICS
2009
8
8
Figure 2.
3
Smart Metering Scope
[16
]
Figure
2.4
Wired and
Wireless Options
[16
]
9
9
2.1
Wireless Comes of Age
The use of radio technology to provide wireless solutions with such devices as
mobile phones, laptop computers and common consumer equipment make the use of
wireless technologies a feasible option for
solutions to provide business capabilities
and remote access to ICS. Many types of wireless communications are usually
distinguished by the frequency band, the standards used, and the primary application.
Many wireless applications such as ZigBee, Bluetoot
h and ZWave have been
implemented as computing and telecommunications solutions in markets such as home
automation and building control, SCADA systems and even livestock control. Many
other commercial options for low power radio have been specifically deve
loped,
evolved and emerged as viable solutions for utility communications. Emerging
implementations include the M
-
Bus standards used for smart metering in northern
Europe, the Wavenis solution used for water metering in France and the Trilliant
platform be
ing used by some utilities in Canada. Utilities in America and Australia
offer a specific Smart Energy profile with ZigBee which was developed to provide
smart metering connectivity to home area networks.
Th
e low
-
power mesh
infrastructure design bounces pa
ckets of data through a
series of nodes to reach their target. This type of network topology offers the
protection of avoiding potential single points of failure in a network. This is critical in
the design of the solution. This type of mesh network increa
ses the power
consumption of every fully functional node. Each node must be able to receive and
10
10
transmit data to and from other close proximity nodes whenever data transfers are
required. Some mesh based devices will be configured as non
-
repeating “end” de
vices
to facilitate lower power consumption
.
2.2
Vulnerabilities
Definition:
A Vulnerability Class is a category of weakness which could
adversely impact
the operation of the Smart Grid.
A
“
vulnerability” can be leveraged
to cause disruption or influence the
Smart Grid [
7
].
Millions of homes and businesses are using smart meters that are riddled with
security bugs that could bring down the power gr
id. Of particular concern, the
new
smart electricity meters are being implemented despite vulnerabilities that can
open
the door to power
-
grid botnets that have been identified in several vendor smart meter
devices. The smart meters provide two
-
way communications between electricity users
and collection devices that ultimately connect to the power plants that serve t
hem.
Utilities in Seattle, Houston, Miami, and elsewhere are hurriedly implementing them
as part of a plan to make the power grid more efficient. Funded by billions of dollars
from President Obama's economic stimulus package, utility organizations have
con
tinued to install the smart meters. Other organizations throughout Europe are also
spending heavily on the new technology. The problem becomes evident when meters
needed to make the smart grid work are built on buggy software that's easily hacked.
Mike Dav
is, a senior security consultant for IOActive
[13
]
has identified several issues
with the smart meter software. These issues are critical to the security of the smart grid
11
11
with the vast majority of them use no encryption and ask for no authentication befor
e
carrying out sensitive functions. There is no validation or authentication when
performing software updates or severing customers from the power grid. Mike Davis
has said the vulnerabilities are ripe for abuse. The smart meters have the capability to
swi
tch on/off hundreds of thousands of homes at the nearly the same time. This can
introduce problems with the power company being able to gracefully deal with power
demands or surges. The
vulnerability in the devices
is susceptible to a worm designed
by Mike
Davis and the IOActive colleagues
to show authoritative agencies the reality
of the problem
. The worm self
-
propagates across a large number of one
manufacturer's smart meter. Once the device becomes infected, the device is under the
control of the malware
developers similarly to the way infected PCs are under the
spell of bot herders. It is at this point that the attackers can “own” the devices and send
instructions to turn power on or off and divulge power usage statistics or sensitive
system configuratio
n settings. The worm is able to spread quickly and exploits an
automatic update feature in the meter that runs on peer
-
to
-
peer technology. The peer
-
to
-
peer technology doesn't use code signing or any other measure to ensure the update
is authorized, but ins
tead uses a routine known as interrupt hooking, which adds
additional code to the device's operating system. There has been no public disclosure
of verified models of smart meters that are designed with these vulnerabilities.
Researchers
,
engineers
and
ven
dors
decline to identify the models or the
manufacturers but will only elaborate to state that most of the models suffer from the
same poor design.
Companies manufacturing the smart meter devices for smart grids
12
12
include GE Energy,
t
he ABB Group, Sensus Met
ering, Itron and Landis+Gyr. The
embedded platforms are not designed for security. One deficiency that has been
identified as common among many of the meters is the use of well
-
known insecure
programming functions, such as memcpy(
) and strcpy(
). These a
re two of the most
common sources of exploitable software bugs. In many cases, the devices use general
purpose hardware and software that aren't designed for highly targeted or mission
critical systems. This is the nightmare of the smart grid security init
iative. Envision a
malicious hacker that has the unique identifier that's printed on your meter.
A security company named ControlScan maintains a database listing
vulnerabilities found in the more common problems found in the Internet
infrastructure. The d
atabase lists
3
5
,
819
total vulnerabilities that have been identified
by ControlScan [14]. This list cannot reflect all the problems in ICS/Internet
infrastructure.
Additional vulnerability
problems and
the
potential impact
listed in a
Vulnerability Classe
s
website
[
3
] attempts t
o list many that
may not be as obvious as
those listed in the ControlScan database.
By 2015, utilities in more than two
-
dozen US states expect to have almost 52
million customers outfitted with the bidirectional smart meters, according to the
Edison Electric Institute, which represents power companies. Some of those
deployments are alread
y completed and many more will be completed in the next few
years.
Attention is now focused to the Tenable Nessus Vulnerability and Compliance
scanner solution.
13
Chapter 3
Nessus Scanning
I
nformati
on on numerous common vulnerabilities has been presented. These
are the well known common problems but some may not be so obvious to newly
trained ICS/Internet personnel. The problems introduced into the AMI/AMR systems
from Internet and networking vulnera
bilities pose a daunting task of identifying and
securing the infrastructure. Many problems are readily apparent and there are those
that are not so easily identified. It would be impossible to manually identify and
mitigate the issues. Nessus has provided
a tool to assist in identifying problems in
AMI/AMR technology. Nessus is an active scanner featuring high speed discovery,
configuration auditing,
asset profiling, sensitive data discovery and vulnerability
analysis. It is a popular vulnerability scanner
that offers many features to help assess
the security of control system networks, devices, servers and workstations. Basic
vulnerability scanning has crashed many control system devices and applications but
new features and techniques make it possible to
scan control system networks with
minimal impact to critical systems such as SCADA. This “safe” feature makes Nessus
an ideal candidate for use with SCADA systems.
Tenable Nessus and Digital Bond have formed a collaboration to extend the scanner.
Nessus
is part of the following Digital Bond Racks:
Control System Security Assessment Rack
Application Security Assessment Rack
14
Web Application Security Assessment Rack
3.1
Bandolier
Related Work
Digital Bond is currently involved in a researc
h project known as
Bandolier
[17
]. It documents the optimal security configurations for control system application
components. Programs are written
into audit files
that can be used in security tools
such as Nessus. Policy compliance checks allow asset owners to verification
that the
system is in the optimal security configuration for both operating systems and
application security settings.
Bandolier audit files are used at initial deployment to
determine baseline configuration and compliance with NIST standards.
Bandolier
is
funded by the Department of Energy (DOE) and is Objective 1 of a larger effort
known as the Cyber Security Audit and Attack Detection Toolkit.
3.2
Compliance Checks
Using guidance from NIST and other industry organizations, Tenable Network
Security has deve
loped best practice compliance checks for many operating systems
and common Internet applications such as databases and web servers. The Bandolier
project is developing files specifically
targeting
control system applications that reside
on a variety of Wi
ndows, Linux, and Unix platforms. The Bandolier audit files can be
used with Nessus compliance plug
-
ins to perform security scans and to compare a
deployed control system component to the best practice security settings and then
identify any variances. The
Nessus compliance plug
-
ins are available to Nessus
15
ProfessionalFeed customers at a cost of $1200 a year with access to new plug
-
ins,
customer support, and access to the SCA
DA plug
-
ins that Digital Bond [6
] developed
for Tenable. Compliance plug
-
ins provid
es the Nessus Vulnerability Scanner with the
ability to audit a system against a secure configuration as described in the policy
compliance file. Bandolier created files can be used with the Nessus Vulnerability
Scanner to audit security configurations of
the twenty
-
plus control systems
applications that are part of the project. Although Nessus is the de
-
facto standard for
vulnerability scanning, there are other tools available that can perform similar
functions. Digital Bond will also make the compliance c
hecks available in the XCCDF
and OVAL formats used by NIST's Security Content Automation Protocol (SCAP).
To provide maximum benefit and reusability for the community, all SCAP validated
scanners will be able to use the Bandolier audit files.
3.3
Compliance Ch
ecks versus
Vulnerability Scans
An important difference exists between compliance checks and traditional
vulnerability scanning in Nessus. Each has its own distinct purpose and value; i.e.,
vulnerability scanning relies on signatures of “known bad things”.
The scanning tests
typically send packets to the device under scan that have caused many control system
applications to crash or operate improperly. On the other hand, compliance checks
compare a system against the “known good”, hardened configuration. Th
is process is
facilitated by creating an authenticated administrator connection to the system and
inspecting its configuration.
16
Different methods are used to determine what services are running on a
workstation or server. Vulnerability scans send a packet
to each TCP and UDP port to
evaluate the response to determine if the port was open. Unfortunately, simple port
scanning has caused numerous poorly written control system applications to fail. On
the other hand, compliance checks connect to the workstatio
ns or servers as an
authenticated administrator to get a list of the services running and return this
information via the administrative connection. It should be noted that an application
that would crash on a port scan would not crash when the same inform
ation was
collected by a compliance check.
Compliance checks can read and evaluate files which makes the number and
types of checks available almost limitless to provide the capability of checking many
built
-
in settings at the operating system level. The f
ollowing examples do not
represent the full array of checks that are available but are meant to only highlight the
capability of the checks. Note that the examples start with basic service evaluation to
very specific application configuration inspection.
3.4
D
evelopment Approach
Step 1: Select the control system applications for project participation.
The development of a methodology to enhance the Nessus Scanning solution
must
be
flexible
so
that enhanced scans can target conventional network systems and ICS
c
ontrol servers and computers. In this context, control system refers to any server or
workstation whether it is connected to ICS or conventional LANs or WANs. The
17
focus is to develop a systematic methodology that can be used in currently
implemented system
s and future implementations. The following are factors that make
a control system application more applicable for a systematic enhanced scanning
methodology to detect and discover vulnerabilities:
Select a control system application running on a relativel
y current operating
system. Exclude systems running Windows 98 or NT.
Select a control system application or component that can be secured.
Applications that cannot be patched or configured in a highly vulnerable
manner will be of little use. The audit can
and will only verify it is an insecure
state.
Select a control system application that is widely deployed. Human Machine
Interfaces (HMI) or operator consoles are ideal candidates because this will
allow a quick and consistent audit of many HMI workstatio
ns. Similarly, if the
same Distributed Control System (DCS) is being used at many power plants
the systems than that DCS would be an ideal choice.
Select a critical control system application. A critical control server is a good
candidate for a compliance
policy file even if there is only a primary and
backup server. The compliance policy file will identify any changes to the
secure configuration.
Similar control system application components with different configurations
can have their own compliancy polic
y. Permissions on different systems could
18
be quite different even though an HMI might run the exact same software as
an engineering workstation.
Inspect logs, research security bulletins, investigate network anomalies for
potential problems that may
possible cause disruptions or outages. This step is
needed to assess the proper operation of the target system. Several different
processes are performed.
Step 2: Develop secure, hardened configurations for each control system
application component
This st
ep is extremely important. The goal is to create a
“gold”
standard
configuration for each control system application component for each of the
components, e.g. HMI, Historian, Realtime Server, and OPC Server. Deployed control
system application components
will be measured against the standard, Scan with
existing plug
-
ins and patch any discovered vulnerability. The ideal scenario is for the
system administrator, SCADA administrator or DCS vendor to assist in this step.
Digital Bond's research team, system ad
ministrators, the vendor and asset owner users
would work together to define the “gold” standard for Bandolier. Consensus
guidelines have been used as a starting point for operating system and common
Internet applications, such as web servers, database app
lications, and security
configuration settings. Modifications are made as needed for the control system
application to function properly, and then the control system application specific ideal
security settings are defined.
19
Step 3: Perform a baseline scan
After the “gold” standard is defined, perform a baseline scan. Any
vulnerability discovered or non
-
compliance should be corrected and the scan run again
till all problems are resolved with the direct fee plug
-
ins supplied by Nessus. After all
problems hav
e been resolved, the scan should be assigned as the original “gold”
standard.
Step 4: Develop Plug
-
ins for Newly Discovered Issues and Checks for Compliance
Not all Bandolier audit templates are developed to measure the same level of
security. A
particular HMI’s gold standard may be much more secure than another
HMI’s gold standard because the vendor may have leveraged operating system
security features and build security features into one and not the other. Bandolier
templates attempt to identify
the best possible security setting for each individual
control system application component.
As of May
, 2010, Tenable Nessus 35.414 plug
-
ins performs a high level of
comprehensive checks. Nessus is not a tool that can “cover all the bases” but is a tool
d
esigned to “cover” a large portion of problems that are nearly impossible to discover
manually. With this in mind, there are problems that may be unique to the
organization and a need for customized plug
-
in to enhance the scanning tool to
discover vulnerab
ilities and check for compliance.
Customized plug
-
ins created to enhance the scanning capability to address any
issue is a critical step that must be done correctly. The plug
-
ins can be written to
20
output a specific message for vulnerability discovery or in
dicate compliance. Any
vulnerability or compliance check file must be written to comply with the Nessus
general guidelines..
Step 4.1 Methodology to Create Nessus plug
-
in
A
Nessus plug
-
ins
is
created according to the guidelines in the Nessus Att
ack
Scripti
ng Language (NASL) [5
]. The guidelines are used for the scanner to make use
of full functionality and to ensure the enhanced plug
-
in behaves properly, especially
on critical computers connected to critical systems. There are three guidelines to
follow.
•
exe
cute only if necessary
•
use other script results by use of dependencies
•
share by saving to KB, upload report results and plug
-
ins
By following this methodology, the Nessus community reaps many benefits.
Discussion forums, support, knowledge base, documenta
tion and users all benefit from
the collaboration.
Step 5:
Create and
Test New Plug
-
ins Before Rel
easing to Production
Skip this
step if no new enhanced plug
-
in has
been developed. Otherwise, the
system administrator will gather information on the system
and will create the
vulnerability and compliance policy files on the
targeted
secured and hardened
configuration. Each test
plug
-
in
task on each system should be thoroughly tested.
Ideally, the plug
-
ins should be tested in a similar lab environment or test
equipment. A
prototype with virtual machines can be used as a test bed to determine plug
-
ins are
21
behaving and not causing problems to the environment. Badly written plug
-
ins can
cause serious problems.
Step 6: Perform “Post
-
Gold” Scan
Perform another
scan to discover any vulnerabilities and checks for
compliance. This scan should indicate full compliance with the “gold” standard
previously defined in
step 2. Any failures indicated in th
is
scan report will need to be
resolved and repea
ted
and begin
at
s
tep 3 and scan till all issues are resolved. At this
point in time, the target system “gold” scan and “post
-
gold
”
scan can be compared in
the Nessus scanner by selecting the option within the Report GUI interface. The
“post
-
gold” scan should be run at pre
scribed intervals to discover if any unauthorized
changes have occurred since the last
“gold”
baseline scan. The
“
gold” standard
documentation and processes may need modification at this step if new plug
-
ins are
written or other standards have been updated
with new configuration. Repeat the
development approach for other target systems that are participating in the project.
3.5
Extending Bandolier with Nessus
Credentialed Scanning
The Bandolier security audit files provide a view of the internal security
config
uration. Some desirable audit results are not available directly from the audit
files or compliance checks. Nessus Credentialed Scanning options are a safe, reliable
method to assess control system servers and workstations.
A p
lug
-
in
is
available to
audit
missing patches at both the operating system and application levels, including
22
some often
-
overlooked client applications. Enhanced plug
-
ins are created to target
specific vulne
rabilities or compliance checks.
Other authenticated scanning options include t
he "netstat" port scanner that is a
safe way to enumerate open ports without a traditional port scan that has been known
to crash some control system applications. This is an extremely important fact since
the control system of a Smart Grid cannot crash un
der any circumstance, especially an
administrator invoked scanning task Unix systems use the command
netstat
-
an
to
return the results. Windows systems use WMI to return the same information.
Nessus offers additional information when credentials are pr
ovided to
authenticate to the remote host. The credential checks are useful when used in
conjunction with a full vulnerability scan and is a safer scanning option to use with
fragile control system
hosts.
The Nessus scan policy provides user credential input to connect to a remote
server or workstation. Nessus is allowed to authenticate to a remote host to use the
built
-
in operating system functionality to run tests that have been defined by the user
in the
scan policy.
The Nessus scanner uses Server Message Block (SMB) for Windows hosts that
require the ability to communicate with the remote host on TCP port 445. The defined
user account in the scan policy requires administrator privileges.
The Ne
ssus scanner relies on Secure Shell (SSH) TCP port 22 for Unix and
Linux hosts. Root access is facilitated through either the root account or an account
capable of using
su
or
sudo
.
23
3.6
Customize
Policies
Several factors
that make the Nessus Scanner an ideal tool for system
administrators is the ability to customize plug
-
ins for very specific needs. This fine
granularity enables each plug
-
in to be used a
s a
building block to address the
multitude of vulnerabilities that can be exploited in SCADA
or network
systems.
Since the integration of the Internet into ICS, it is difficult to discover all the
vulnerabilities that have surfaced in the system.
As of April
2010,
Nessus includes a
list of over 3
5
,
819
plug
-
ins used for discovering vulnerabilities. However, the case
may exist where no plug
-
in has been written for a particular case.
At fist glance, it appears like a comprehensive list of plug
-
ins is available f
or
Nessus scanning. Research shows that there has not been a plug
-
in written to address
CVE
-
2010
-
0806 “Peer Objects” component involving access to an invalid pointer
upon the deletion of an object. Otherwise known as an “Uninitialized Memory
Corruption Vul
nerability”, exploits have surfac
ed in the wild in March 2010 [10] [11
].
The following NASL code [
5
] was written to address this vulnerability.
#
# iepeers.dll 0
-
day vulnerability script
# (free
-
after
-
use
# aka Uninitialized Memory Corruption Vulnerability
)
# CVE Reference: CVE
-
2010
-
0806
# Written by Raymond Cordova
# Test Script to detect 0
-
day vulnerability in Internet
Explorer
24
#
include("compat.inc");
if (description)
{
script_id(50003);
script_version("$Revision: 1.0 $");
script_name(english:"iepeers.d
ll 0
-
day vulnerability
in Internet Explorer versions 6 or 7");
script_summary(english:"Checks Internet Explorer
version for 0
-
day free
-
after
-
use vulnerability.");
script_set_attribute(attribute:"synopsis", value:
"A older version of Internet Explorer (6 or
7) is
installed on the remote host.");
script_set_attribute(attribute:"description", value:
"A version of Internet Explorer (6 or 7) is installed
on
the remote host. Data Execution Protection (DEP)is
enabled by default in IE 8.0 which helps mitigate
attacks against it.
Microsoft recommends that users upgrade to version 8
for better security. Note that there are unconfirmed
reports from Secunia program and computer online
25
scanners report that version 8 is also vulnerable to
the iepeers.dll vulnerabilit
y using ActiveX.");
script_set_attribute(attribute:"see_also", value:"
http://blogs.technet.com/msrc/archive/2010/01/14/secur
ity
-
advisory
-
979352.aspx
http://www.cve.mitre.org/cgi
-
bin/cvename.cgi?name=CVE
-
2010
-
0806
http://www.vul.kr/microsoft
-
internet
-
explo
rer
-
iepeers
-
dll
-
use
-
after
-
free
-
exploit
-
meta
http://www.microsoft.com/technet/security/advisory/9813
74.mspx
http://secunia.com/advisories/38860/");
script_set_attribute(attribute:"solution",
value:"Upgrade to Internet Explorer 8." );
script_set_attribute(at
tribute:"risk_factor", value:
"Medium");
script_set_attribute(attribute:"plugin_date",
value:"2010/03/28");
script_end_attributes();
script_category(ACT_GATHER_INFO);
script_family(english:"Windows");
script_copyright(english:"This script is a test scr
ipt
written by Raymond Cordova.");
26
script_dependencies("smb_hotfixes.nasl");
script_require_keys("SMB/IE/Version");
script_require_ports(139, 445);
exit(0);
}
include("global_settings.inc");
include("smb_func.inc");
port = kb_smb_transport();
version = get
_kb_item("SMB/IE/Version");
v = split(version, sep:".", keep:FALSE);
if ( int(v[0]) > 5 && int(v[0]) < 8 )
{
if (report_verbosity > 0)
{
report = '
\
n' +
"Internet Explorer version " + version + " is
installed on the remote host. The iepeers.dll
is
vulnerable to exploits.
This vulnerability
exploits the “free
-
after
-
use invalid object
pointer after object deletion
" + '
\
n';
security_warning(port:port, extra:report);
}
else security_warning(port);
27
exit(0);
}
else exit(0, "Internet Explorer version " + v
ersion + "
is installed on the remote host. The iepeers.dll is
vulnerable to exploits.");
Script
3
.1 XP “iepeers.dll” 0
-
day Vulnerability Script
Script 3.1
will scan, detect, report and suggest a solution to the vulnerability, if
found. The methodology used includes the use of previously written code by the use of
a dependency statement in the code. e.g., script_dependencies(). Also, local
Knowledge Base ite
ms stored on the local server are accessed for use with
script_require_keys() statement. Utilizing these functions allows for enhancing the
performance and overall effectiveness of the scan.
As of April 2010, the script has been modified slightly to Versi
on 1.1 to reflect
additional
research
of the reports of Secunia’s online scanners.
Unconfirmed reports
stated that t
he online scanners indicated reports that Internet Explorer 8 is also
vulnerable
to the iepeers.dll vulnerability using Active X. Research s
hows the scanner
did not produce any
of these
indications on a Windows 7 Operating System with
Internet Explorer 8. The system is fully patched and
the iepeers.dll script was modified
to indicate that Internet Explorer 8 is vulnerable to re
mote attacks by
other methods as
reported by Microsoft Security Bullitens.
28
# Windows Compliance Check for XP computers
# Checks for disabled USB Storage Devices
# Version 2 Windows Compliance Plugin
# Written By Raymond Cordova
<check_type: "Windows" version: "2">
<
group_policy: "Audits Windows 2003 Systems for disabled
USB Storage devices.">
<custom_item>
type: REGISTRY_SETTING
description: "USB Storage Devices Are disabled"
value_type: POLICY_DWORD
value_data: 4
reg_key: "HKLM
\
SYSTEM
\
CurrentControlSet
\
Services
\
UsbStor"
reg_item: "start"
reg_type: REG_DWORD
</item>
</group_policy>
</check_type>
Script 3
.2 XP USB Storage Devices Disabled Compliance Check Audit
Script
29
# Windows Compliance Check for XP computers
# Checks for disabled CDROM autorun
# Version 2
Windows Compliance Plugin
# Written By Raymond Cordova
<check_type: "Windows" version: "2">
<group_policy: "Audits Windows Systems for CD AutoRun
disabled">
<custom_item>
type: REGISTRY_SETTING
description: "CD AutoRun Disabled"
value_type: POLICY_DWORD
v
alue_data: 0
reg_key:"HKLM
\
SYSTEM
\
CurrentControlSet
\
Services
\
Cdrom"
reg_item: "AutoRun"
reg_type: REG_DWORD
</item>
</group_policy>
</check_type>
Script
3
.3 XP CDROM Auto
-
play Disabled Compliance Check Audit
Script
30
<check_type:"Unix">
<custom_item>
type:FILE_CONTENT_CHECK
description:"Check if Permit
RootLogin is set to no
and not
commented for
the
server."
file:"/etc/ssh/sshd_config"
regex:"^ *[^#]*PermitRootLogin *"
expect:"PermitRootLogin no"
</custom_item>
</check_type>
Script
3
.4 Fedora 12 SSH Re
mote
Root Login Disabled Compliance
Check Audit Script
Following the Nessus best practices presente
d in the NASL Reference Guide
[5
], the code was written to address only one vulnerability in each plug
-
in. In this way,
the plug
-
in can be used with
future or existing plug
-
ins as a building block that
becomes a building block of a complex collection of plug
-
ins.
31
3.7
Nessus Scan Performance Metrics
Nessus scans were performed on the prototype and ISSG lab computers. The
prototype layout is shown in Figure
3.1
.
Prototype Layout
5/10/2010
12
ENSDV / Cordova
Figure
3.1
Prototype Layout
The Nessus scanner used was version 4.2.1 build 9119 with the
ProfessionalFeed su
bscription services with updated plug
-
ins. Full scans were
performed with CGI, Web application tests and thorough testing enabled. Safe
checks were
also
enabled.
Administrator credentials were provided in the Nessus
policy.
Older machines such as the physical XP patched
prototype
machine did not
perform well. Several applications and services installed on this machine have it in an
32
“overloaded” condition. The machine has a 1GHz PIII with 512 RAM and is very
slow when working
on a modern application
, especially when targeted for scans
.
Many
factors affect scan time performance
:
•
Hardware
•
Operating System
•
Applications
•
Services
•
Network Infrastructure
•
Nessus server Host
•
Firewall
•
Passive or Active IDS/IDP
Prototype
Target Machines
Seconds
3Com SSS HP Procurve VXWorks
723
HP Jet Direct Printer
253
Windows 7 Home
-
physical
565
Windows Server 2003 VM
242
Windows XP Pro un
-
patched VM
279
Linux Kernel 2.6 VM
874
Windows XP Pro
patched
-
physical
1153
Table
1.
Prototype Nessus Scan Time
33
Figure 3.2
Nessus Scan Performance Times on Prototype
Nessus scans were performed on the ISSG lab computers on subnets
128.198.60.0 and 128.198.62.0. The scan discovered 34 machines active on the
network. Full scans were performed with CGI, Web application tests and thorough
testing enabled. Safe checks were
enabled.
Credentials were not provided in the
policy.
A previous
credentialed scan discovered 31 machines active on the network.
There were 3 machines turned
on
between the
two
scans.
Note that the machines that
took the
longest
had indications of web ap
plication services installed.
34
Target Machines
Seconds
128.198.60.1
128.198.60.127
128.198.60.129
128.198.60.18
128.198.60.181
128.198.60.63
128.198.60.65
128.198.62.1
128.198.62.120
128.198.62.131
128.198.62.184
128.198.62.185
128.198.62.186
128.198.62.2
128.198.62.25
128.198.62.26
128.198.62.3
128.198.62.90
128.198.62.91
128.198.62.92
128.198.62.93
a
-
212
-
01.csnet.uccs.edu
a
-
212
-
02.csnet.uccs.edu
a
-
212
-
03.csnet.uccs.edu
a
-
212
-
04.csnet.uccs.edu
ace.csnet.uccs.edu
b2b.csnet.uccs.edu
bilbo.csnet.uccs.edu
gandalf.csnet.uccs.edu
se
-
a210
-
05.csnet.uccs.edu
sis.csnet.uccs.edu
viva.csnet.uccs.edu
walden.csnet.uccs.edu
walrus.csnet.uccs.edu
blanca.uccs.edu
409
413
412
5830
368
417
402
455
530
1372
429
464
460
461
4864
565
456
586
675
767
701
32
0
324
385
362
1117
373
466
4233
354
372
5272
781
4587
5666
Table
2
. ISSG Nessus Scan
35
Several factors affect the scan time on the target machines.
T
he scan takes
longer on machines
that have web services installed or have many State Service
instances
. The Viva server took 5,272 seconds to complete. The scan
found several
web server
instanc
es and launched a series of plug
-
ins for testing the
installation.
Also,
the
q
uad core
3.6 GHz processors, 4GB RAM, and 2MB cache result in lower scan
times on Blanca. Athena, Gandalf and Viva nearly took twice as long for scans to
complete mostly
due to
h
ardware
differences from Blanca
.
Note:
For additional assessment of Nessus scan performance, please refer to
http://www.nessus.org/documentation/index.php?doc=
nessus published
by Tenable
Nessus
[
19]
.
36
The targeted
machine specifications are
:
•
Athena
-
PowerEdge 2410
•
4GB RAM, L1 I 16K, L1 D 16K, L2 512K
•
Dual Pentium III CPU 1.3 GHz
•
Linux version 2.6.26.8
-
57 fc8 Fedora release 8 (Werewolf)
•
Blanca
-
Precision 670
•
4GB RAM, L2 2M
•
Quad Xeon Irwindale CPU, 3.6 GHz
•
Linux version
2.6.18
-
128.1.10.e15 CentOS release 5.3
•
Gandalf
-
Dell GX 270
•
1 GB RAM, L2 512KB
•
Single Pentium IV G0101 CPU, 3GHZ, 800FSB
•
Viva
-
Optiplex GX 620,
•
4 GB RAM, L1 D 16K, L2 1MB
•
Dual W9446 Processor Pentium D Smithfield for Desktops, 3.2 GHz
•
2.6.30.10
-
1
05.2.23.fc11.i686.PAE Fedora 11 (Leonidas)
37
Figure
3.3
Nessus
Non
-
credential Scan Performanc
e Times
i
n
ISSG Lab
Figure 3.4 scan result with no credential configuration indicates a shorter
period of time for the scan to complete. Figure 3.5
indicates longer periods of time
before the scan completed. Credentialed scanning took slightly over 36% longer than
non
-
credentialed scanning.
38
Figure
3.4
Nessus
Non
-
Credentialed Scan on ISSG Lab
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
128.198.60.18
Athena
128.198.162.60
Blanca
128.198.60.194
Gandalf
128.198.60.192
Viva
Target Machines
Target Machines
39
Figure
3.5
Nessus Credentialed Scan on ISSG Lab
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
128.198.60.18
Athena
128.198.162.60
Blanca
128.198.60.194
Gandalf
128.198.60.192
Viva
Target Machines
Target Machines
40
Results of the two different scans indicate how different configuration can
affect the scan performance.
Four machines were targeted:
Athena.csnet.uccs.edu
Blanca.uccs.edu
Gandalf.csnet.uccs.edu
Viva.csnet.uccs.edu
The policy configuration was ident
ical except for the credential configuration in
which credentials were provided for one scan and not the other. It should be noted
that credentialed scanning invokes additional plug
-
ins for a more comprehensive scan
result.
Additionally, scans will only r
un plug
-
ins that are pertinent in a cascading
fashion, e.g., if the web application test is enabled and a web application is found on
the target machine, more scan tests will be launched against the target. If no web
application is found, the web tests wil
l terminate and scan time is reduced. .
41
Chapter 4
L
essons Learned
4.1 SCADA Access
As plans unfolded for research in ICS and Internet integration emerging
technology and security of the systems, several unforeseen issues began to surface.
The
first realization of difficulty focused on the problems with procuring a prototype
that could simulate a SCADA infrastructure. When asked about test access to a
SCADA test bed, a quote from an email from Renaud Deraison of Nessus simply
states, “That's the
biggest problem with SCADA”, indicating no test scans can be
tested on the SCADA system unless special permission is granted through contract
agreement. Ultimately, no access to any test bed or system could be established
because of the stringent security
of the ICS.
4.2 Meter
and Development Kit P
rocurement
While attempting to procure smart meters and collection points for lab testing,
s
everal vendors were hesitant to provide any information about their product for fear
of divulging trade secrets and
discovering unknown vulnerabilities. This
procurement
proved difficult to implement because of vendors at Byram Labs
offered meters at a
cost of nearly $3000 to
provide a few meters of different models but the collection
points w
ould cost
$900
for an
onlin
e monitoring service
in 6 month time periods.
Other vendors provided meters only for authorized buyers. And others would allow
purchase of a smart meter but provided no support for interface support, code
42
enhancement, development or hardware.
It became ap
parent meters purchased
directly from a vendor would not fulfill thesis research requirements to enhance
network scanning for discovering vulnerabilities.
Several development kits could simulate a “Smart Meter” but cost, interface
hardware, software, a
nd
the
ambiguity of what is specifically needed made the
decision difficult.
Extensive r
esearch showed the TI
CC2530ZDK
MSP2530 ZigBee
and ZigBee Pro development kit to be a good candidate for conducting meaningful
research. The
development
kit costs $649
and has a “Sample before Buy” program
that allows for users to order different hardware samples for testing in the kit. This kit
allows for testing of several different low
-
power RF processors and protocol stacks
currently used in TI’s solution for Smart M
eters. Also considered was the
CC430 that
integrates the latest MSP430F5xx to develop an entire wireless project. However,
more functionality and flexibility is integrated in the MSP2530 development kit with
the more secure Smart Meters using this hardware
.
Another candidate development kit is the CC2430 System
-
on
-
Chip solution for
2.4 GHz IEEE 802.15.4 / ZigBee. The ZStack library version 2.2.2
-
1.30 used in the
CC2430 and CC2530 microcontrollers uses an insufficient random Psuedo
-
Random
-
Number
-
Generato
r (PRNG) for cryptographic signatures and session keys. PRNG data
repeat every 32,767 samples, and there are at most 16 bits of entropy in any key.
Searching the entire key space is possible without investing a lot of time. The random
numbers must
not
be u
sed to generate random keys used for security purposes.
The
flaw is that the PRNG is not cryptographically secure and is that it is seeded from a
43
random source that has very little entropy.
The weakness ought to serve as a
cautionary tale for the untold nu
mber of companies working on parts with stimulus
monies that will make up the emerging smart grid. So it became a time consuming
research task to determine if the Zigbee stack shipped with the development kits
CC430 and CC2530 shipped with the latest versi
on 2.3.0 which relies on the fact that
the Zigbee stack in these kits is
not flawed.
4.3 Nessus Scanner
The Nessus demo version was selected for the functionality, flexibility,
customizable, powerful, automated, safe scanning tool that it is
advertised as. Nessus
boasts it is a centralized invaluable tool for ICS/Internet administrators to simplify the
daunting task of securing the ICS/Internet infrastructure. The decision was made to
test the tool with credentialed scanning and customize plug
-
ins for enhancing the tool
to add meaningful value. The focus was to identify a
nd focus on a
methodology to be
used as a foundation to be used to meet the
security
requirements of the various
enterprise organizations. The Nessus HomeFeed version was down
loaded and it was
soon discovered that the tool functionality is limited to basic scanning. It became
evident the HomeFeed version would not meet the requirements to fulfill research,
m
ethodology and enhancement goals.
Renaud Deraison at Nessus was contact
ed through email with a request for the
ProFeed version. Project information was provided and Renaud provided a fully
functional version of Nessus ProFeed. The ProFeed version provided additional
functionality:
44
Report comparison
Resolved inconsistencies in
the c
reat
ion of
custom plug
-
ins
Re
-
index DB inconsistencies
Display issues with plug
-
ins
The Nessus ProFeed exhibited odd behavior with custom plug
-
ins.
Re
-
index DB inconsistencies
unless the DB is purged and rebuilt
Display issues with plug
-
ins
Re
-
named
plug
-
in is run twice
if ID is not updated
Re
-
named plug
-
in is displayed twice
in plug
-
in dialog window
The solution to rebuild and re
-
index the database was attempted to resolve the
problems encountered with custom plug
-
ins. The command “:>
"c:
\
Program
Files
\
Tenable
\
Nessus
\
nessusd.exe"
-
R 3 was entered in a command prompt. The “
–
R”
and the number “3” switch options rebuild the database with a complete flush, rebuild
and re
-
index. The procedure to logout of the client, stop the Nessus server a
nd execute
the command failed. The command prompt immediately returned and the server would
not restart. The installation was repaired through the Control Panel Programs applet
and the server restarted successfully. However,
a duplicate plug
-
in was
still l
isted and
the scan report indicated two instances of the sa
me plug
-
in although the plug
-
in was
named differently. The underlying cause was the plug
-
in ID number was identical
to
another plug
-
in and
that the ID number was not changed during the renaming
pro
cedure. This effectively caused a collision of the plug
-
ins in the database and the
cached plug
-
in mechanism. Two mistakes were made
during this process
. Renaming a
45
plug
-
in requires the ID to be changed immediately before the server is restarted or
initiat
ing a plug
-
in update
through server manager. The re
-
index command failed
because the server manager window was still open even though the server was
stopped.
T
he server manager
window
must
be closed
prior to rebuilding the DB.
When starting the Nessus Ser
ver Manager, the user must wait about a 10
-
30
seconds before starting the client. Although the server indicates the service is started,
there is obviously some
background process still starting
that the client depends on to
successfully connect to the serv
er.
Figure
4
.1 Successful Nessus Database Rebuild and Re
-
index
4.4 Digital Bond Bandolier Project Compliance Check
Plug
-
ins
Preliminary research direction focused on the Bandolier files delivered to
Nessus for SCADA compliance checking. The idea was to investigate the files for a
better understanding of scanner use with compliance check audit files.
This tool is
further
suppor
ted by
the D
igital Bond Bandolier project [6
].
Nessus has been approved
by North American Reliability Corp. (NERC) Critical Infrastructure Protection (CIP)
46
as a tool for scanning SCADA.
Plug
-
ins are custom written to
scan SCADA
network systems and require
subscription services for full functionality and update
s
ervice
. The
Bandolier project has provided forty 40 n
ew plug
-
ins
specifically written
for SCADA
as of May 2010
The plug
-
ins are pre
-
compiled Nessus binary (.nbin file
extension) files that could not
be analyzed unless they are reverse engineered with an
application similar to IDA Pro. This made it difficult to analyze and research the
se
scripts
.
Deeper research revealed many of the “nbin” files are run
only
as compliance
checks for
SCADA
vendor speci
fic applications
and focus was shifted away from
analyzing these files
.
Two audit files were disassembled and analyzed. It became
evident that it would not be advantageous to continue in this direction.
4.5 Nessus Attack Scripting Language (NASL)
The
Nessus Att
ack Scripting Language (NASL) [5
] is a new language
I needed
to learn before any scripting or customizing
could
be done. The reference manual was
studied and test scripts were written to tune skills for the methodology to write custom
scripts. The NASL interpreter proved to be very unforgiving. A space in the script
would render the script
non
-
executable and could o
nly be discovered by brute force
trial and error
. R
unning the mis
-
behaved script resulted in script errors in the report.
Of particular conce
rn is
the Windows Compliance check ID 51126 and Unix
Compliance Check ID 51127 scripts. During the creation of an e
nhanced script for
detecting SSH remote root login, the report indicated a conflict in version 1 and 2 of
the compliance scripts. The windows script worked but the Unix Compliance Check
ID 51127 would report “check_type” not set in the created custom scrip
t. Research of
47
Nessus documentation and discussion boards indicated that “v2” be appended to the
filename and the opening <“check_type : “Unix” version:“2”> and closing
</check_item> tags are required for the version 2
plug
-
in
. The Nessus database is re
-
i
ndexed with a nessus
–
t command to accept changes to any plug
-
ins. The nessus
–
D
is used to re
-
build the database. The Nessus service is restarted and errors persisted.
The script was re
-
written from scratch with a backward compatible version 1 format
and
received a parse error indicating “ “ in line 3. The space was removed and the
script successfully completed. A version 2 script was re
-
created and fails with the
same indications. The limited resources of discussion boards, limited support,
documentation
all indicate the <check_type> tags should be included in version 2 but
clearly do not work for Unix compliance checks. Issues appear to be an unforgiving
syntax error in which a “space” before or after the script statements cause an error at
run time and
the version 2 syntax not recognized correctly in Unix Compliance Check
ID 51127. Renaud Deraison of Nessus has confirmed that the version 2 syntax is not
functional in the Unix compliance checks and only works with Windows.
4.6 VMware
The VMware serve
r console was selected as the Virtual Machine solution for
simulation of a computer systems connected to SCADA systems. The VM server
software would not install on the un
-
supported laptop hardware and had to use VM
Workstation or Player trial versions. Fou
r machines were configured as W2K3
unpatched, XP unpatched, Ubuntu 10 beta and Fedora 12 with telnet enabled. The
virtual machines were then scanned and the XP un
-
patched machine was scanned
48
successfully with administrator credentials. The W2K3 machine
ret
urned with
limited
results. It could
not
fully
be scanned with credentials since no domain was
defined. The Ubuntu 10 machine
was
scanned
resulting in
no critical vulnerabilities
found since no plug
-
ins have not been written for the Beta version of Ubuntu
10.
Although there are Ubuntu plug
-
ins for earlier versions and the scan runs against
Ubuntu 10, earlier version plug
-
ins are not executed.
Fedora 12 was configured with
telnet services and SSH remote root login enabled. Scans produced a report indicating
both risk configurations on Fedora 12.
Difficulties surfaced with the virtual machines. The XP un
-
patched machine
became corrupt and had to be re
-
installed. It should be noted no scans were run on the
XP machine prior to the corruption a
nd had been powe
red down
shortly after
it was
created.
It is not known why this occurred.
The Fedora 12 and W2k3 machines lost network connectivity when testing at
UCCS. The Windows 7 laptop performed very well with all 4 virtual machines active.
However, attempting to r
un a Nessus scan on the virtual machines while connected to
the UCCS wireless campus resulted in no scan run on any virtual machine.
Re
-
testing
on the home prototype
wireless LAN successfully completed
.
Connections on the
“bridged” network adapter need
ed
t
o be configured as “host only” for successful
network connectivity between the host machine and the virtual machines. The scans
were successfully completed at home and UCCS
and
re
-
testing proved successful.
After 9 months of research spent gathering info
rmation, developing, testing, and
proving concepts, I feel I have the expertise to perform cutting edge network scanning.
49
Chapter 5
Future
Direction
5.1 Texas Instruments Development Kits
R
esearch
can be c
ontinue
d
in
a
lab setup of
Texas Instrument’s
MPS2530
micro
-
controllers
. This developm
ent kit can be used to assess Texas Instrument’s
smart meters that are currently being used in the United States. The micro
-
controllers
are advertised as NIST CIP
compliant;
however, there are vulnerabilities in the
MPS2430 series meters.
Research
and development
is needed for the
creation of
enhanced
plug
-
ins to check the ZigBee stack version for
the
Pseudo Random Number
Generator (PRNG) vulnerability
. ZigBee stack versions greater than
version
2.
3 do not
exhibit t
he (PRNG)
vulnerability
.
5.2 Automatically
Patching Failed Compliance
Checks
In a related area of work, Digital Bond and the Bandolier project have
provided 40 specifically targeted compliance plug
-
ins for SCADA.
The plug
-
ins are
Ne
ssus binary pre
-
compiled files with
an
“
.nbin
”
file extension.
A possible r
esearch
project
can be performed
to research the compiler
for the
possibility to integrate
the
audit file lang
uage with C+
for automatic patching of specific security vulnerabilities.
The compliance check file, registry key, web banner, configuration file, etc. is already
known to the plug
-
in and it would be matter of changing a value from “yes” to “no”,
50
as such in the case o
f “PermitRootLogin Yes” for Fedora Core 12. The C+ language
is recognized by the Nessus interpreter.
5.3 Shared Plug
-
ins
As of
April
2010,
Tenable Nessus provides 35,
819
plug
-
ins to
a
scanner that
can be
updated daily. There are vulnerabilities that
have not been addressed by the
direct feed plug
-
in subscriptions from Tenable. A possible research project can focus
on the methodology presented in this thesis to
contribute to the creation of plug
-
ins to
s
hare among the Nessus community
. This can become
a great contribution if an
ongoing
comprehensive
effort
is undertaken
.
5.4 OS Extensions
The Windows vulnerability and audit files can be tailored for different
Operating Systems (OS). The registry keys being inspected are unique to different
OS’s and c
an be quickly and easily modified for different versions of Windows. This
process entails determining the correct registry keys and configuration files for
inspection
for each OS
.
5.5 System Alert for Detecting Plug
-
in Removal
Lastly, I can envision a proj
ect for future work
to alert
the administrator that a
customized plug
-
in has been removed form the plug
-
in directory.
However, if the
custom plug
-
in is uploaded to Nessus direct feed subscription services, the update
51
would download the plug
-
if non
-
existent in local directories
. This is the Nessus
community idea of sharing.
If it is simply a local custom plug
-
in not being shared and not uploaded to
Nessus, the code alert project would be interesting to implement. Perhaps some code
to dete
rmine if the plug
-
in directory size decreases could be used as a trigger for the
alert. The directory should only grow.
T
he
plug
-
in
cache will already contain a copy
and would still run even if the custom plug
-
in is removed.
Cached plug
-
in execution
can c
ause problems with correct scan results.
- Accueil
- Explorer
- Toutes les categories
- Applications d'entreprise
- Biotechnologie
- Divertissement
- Développement de logiciels
- Electronique - Appareils
- Gestion
- Gestion des données
- IA et Robotique
- Internet et le développement Web
- Les technologies propres
- Mobile - sans fil
- Mécanique
- Pétrole et offshore
- Réseaux et Communications
- Semiconductor
- Serveurs
- Stockage
- Sécurité
- Télécommunications
- Urbain et civil
- Communauté
- Ajouter
Commentaires 0
Connectez-vous pour poster un commentaire