raymondENSDV_V2x - College of Engineering and Applied ...

pleasantrollSecurity

Feb 16, 2014 (3 years and 1 month ago)

119 views






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.