DOI: http://dx.doi.org/10.14236/ewic/ICS2015.7

Analysis of Exploitable VulnerabilitySequences in Industrial Networked

Systems: A Proof of Concepts

Manuel Cheminod, Luca Durante, Lucia Seno, Adriano ValenzanoNational Research Council of Italy – IEIIT

c.so Duca degli Abruzzi 24I-10129 Torino

Italywww.ieiit.cnr.it

manuel.cheminod, luca.durante, lucia.seno, adriano.valenzano@ieiit.cnr.it

Software vulnerabilities can affect the security of any computer and industrial networked systems are noexception. Information about known vulnerabilities and possible countermeasures is being collected andpublished since several years, however the methodical introduction of changes and/or software patches inmany industrial networks is not always possible, so that some known flaws can be left untreated as they arenot considered harmful in principle. Unfortunately, a suitable combination (sequence) of vulnerabilities whichare not dangerous when considered as insulated, can provide undesired attack paths to malicious users. Thispaper deals with the automated discovery of such sequences of known vulnerabilities in industrial scenariosby leveraging an analysis framework already developed for the verification of access control policies in real-world systems.

Keywords: industrial distributed systems, software vulnerabilities, automated analysis

1. INTRODUCTION

Modern control systems distributed over a network(DCS) are pervading an increasing number ofapplication areas including, for instance, factoryautomated plants, advanced manufacturingsystems, intelligent transportation systems, smartgrids and critical infrastructures. Because of the evergrowing connectivity of DCS, which more and morefrequently include interfaces to public networks andthe Internet, and the widespread use of advancedcommunication technologies such as wireless net-works, the adoption of methods and mechanisms togrant an adequate level of security is now perceivedas a basic requirement in the design, deploymentand operation of DCS Granzer et al. (2010); Lin et al.(2009); Shakshuki et al. (2013); Cheminod et al.(2013). Generally speaking, this need emergeswhenever technical solutions borrowed from theinformation and communication technology (ICT)world are used in the supervision, monitoring and/ormanagement of some physical system as in thecase of chemical process control, gas, oil andenergy production and distribution networks, roboticand highly automatized plants and so on.

As a matter of fact, real ICT software (s/w) and hard-ware (h/w) components are not perfect and, unavoid-ably, include design and implementation bugs thatcan be exploited by malicious users to jeopardize thesecurity of specific equipment, devices or even wholenetworked systems Cheminod et al. (2013). Suchkinds of flaws are better known as vulnerabilitiesand represent potential security weaknesses thathave to be corrected or taken under strict controlat least. It is worth remembering that vulnerabilitiesare not the same as attacks, but rather a meansto make possible attacks successful. Moreover, inorder to be actually dangerous, vulnerabilities mustbe exploitable, that is an attacker should be put inthe condition of taking advantage of the vulnerabilityitself. Non-exploitable vulnerabilities, that are possi-bly present in a system, are not worrying in principle,because they cannot be leveraged to perform attacksand do not need to be fixed mandatory. This aspectcan be of particular interest (and useful if dealt withcarefully) in many kinds of DCS, where the intro-duction of changes in the h/w and or s/w is hardlypossible or simply not convenient from an economicpoint of view. In this case, in fact, the presence of

c© Cheminod et al. Published byBCS Learning & Development Ltd. 63Proceedings of the 3rd International Symposium for ICS & SCADA Cyber Security Research 2015

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

vulnerabilities can be tolerated until they are provennot to be exploitable for causing harms/damages tothe people, the system and the environment.

Software vulnerabilities are much more frequentand easy to spread than hardware flaws and havebeen receiving particular attention since severalyears. Several publicly-available databases MITRE(a); NIST (NIST); OSVDB (OSVDB); Sufatrioet al. (2004) have been set up to collect andshare information about known vulnerabilities andare regularly updated as new security flaws arediscovered. To the best of our knowledge, norepository is specifically tailored to either industrialcontrol systems (ICS) or supervision, control,monitoring and data acquisition systems (SCADA),thus vulnerabilities concerning ICS and/or SCADAare mixed up with those affecting general-purposeICT systems, and only keyword-based searches inthese databases (e.g. SCADA, PLC and so on) canproperly filter elements of interest.

Even when an existing vulnerability cannot beconsidered dangerous (not exploitable) on its own,it can become useful to the attacker because of thepresence of other different flaws in the same system.This exposes the system itself to attacks than canbe carried out by leveraging suitable sequences (orchains Cheminod et al. (2009); Maggi et al. (2008))of vulnerabilities, that represent a sort of path theattacker can follow to achieve his/her malicious goal.Understanding whether a system includes some ofthese attack paths and finding suitable ways to breakthem are important issues for assuring adequatelevels of security to DCS.

In the past, our research was oriented to theanalysis of attacks to industrial distributed systemscarried out through sequences of known vulnerabili-ties Cheminod et al. (2009); Maggi et al. (2008). Theapproach we adopted made use of a rough-grainedabstract model of the system that had the advantageof enabling a fast analysis (as also recognizedin Ma and Smith (2013) with a proposal inspiredby Cheminod et al. (2009); Maggi et al. (2008)),but also exhibited some drawbacks. In particular, wefound it was quite difficult keeping the model alignedwith the actual implementation of the system itself,and maintaining adequate track of all those imple-mentation details that could make the differencebetween a satisfactory and an oversimplified modelfrom the analysis point of view. These aspects, inour experience at least, tended to become hard tomanage as the system size and complexity grew.

More recently we have focused on the definitionand development of a framework for the automatedverification of correct implementation of accesspolicies defined at a high level of abstraction,

which is particularly suited to industrial networkedsystems Bertolotti et al. (2015). One peculiaraspect of this approach is the construction oftwo different views of the system to be analyzed,which take into account respectively an abstractspecification of policies and a detailed descriptionof the implemented system. The aim of this paperis proposing a suitable extension of this analysisframework to enable the study of sequences ofvulnerabilities in DCS and to prove its conceptualfeasibility through a simple example.

The paper is then structured as follows: Section2 briefly recalls the main characteristics of theanalysis framework that are needed to understandthe remaining part of the paper. Section 3 dealswith the extensions and changes needed to enablethe description of vulnerabilities in the system modeland to allow the subsequent search for possiblesequences of exploitable flaws. Section 4 presentsa small example showing how the underlyinganalysis can be carried out in practice while someconclusions are drawn in Section 5.

2. ANALYSIS FRAMEWORK

Our analysis framework is based on the ability tomodel the system characteristics of interest fromtwo different points of view. Fig. 1 shown the basicblocks building up our approach. In practice, thedesigner has to provide an high-level definition of thesecurity policies to be analyzed (access policies inour previous studies) and a fine-grained descriptionof the system implementation including its securitymechanisms and settings. These two descriptionsare then processed by an automated analyzer toproduce two disjoint sets of (user,object,operation)triples taking into account all the actions thatcan be performed by all users on all objects inthe system. Users, objects and operations are“bridging” elements between the two views and,roughly speaking, the related triples are used by theautomated analyzer to make a comparison betweenthe actual system configuration and its (expected)high abstraction level behavior, in order to highlightdifferences and inconsistencies representing designor implementation flaws.

The implementation view of the system consists ofa data model D describing all objects and theirphysical and/or logical interconnections, the initialstate for each user (i.e. physical location, ownedcredentials and so on) and a set of inferencerules that interactions between the user and thesystem must obey. Inference rules are used by theautomated analyzer to compute the set of all actionsallowed to the user and to build the correspondingtriples in the implementation view. An exhaustive and

64

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

Figure 1: Building blocks of the analysis framework

formal description of the model, its elements andrelationships can be found in Bertolotti et al. (2015).To keep the computational complexity and the stateexplosion problem under control, we consider thesystem static, i.e. interactions between users and thesystem do not affect the latter. Effects of changesin the system can be evaluated with new runsof analysis after modifying the system model asneeded.

Formally, the data model D is a pair:

D ::= (Ω, Λ) (1)

where Ω ::= {ω�} is the set of objects, that is the setof all elements of the system on which operationscan be performed. Objects include rooms and othercontainers (e.g. cabinets), host devices (e.g., PCs,PLCs and so on) and relevant software services(e.g. web and database servers, mail servers, s/wapplications), and network devices for traffic control(e.g. firewalls, switches, routers).

Λ ::= {λ} keeps track of all physical networkconnections.

Any object ω� ∈ Ω is then formally described as

ω� ::=〈ωid, {π�}, ωpath, {acc}, {pp}, {fr}, {sw}〉 (2)

ωid and ωpath in Eq. (2) are an object identifierand a pathname respectively. Since objects can benested in the data model (an object can containobjects and can be contained in other objects, thusallowing, for instance, the description of virtualized

hosts nested within hypervisors) anyone of themis uniquely identified by both its identifier ωid andits path ωpath = ωid1 , ωid2 , . . . , ωidk

, that is theordered sequence of identifiers of the k objects thatneed to be “crossed” to access the target one. Theunique identifier of an object is obviously given byω = ωpath, ωid. To keep the notation as simple aspossible, in the following we will use the shortestsuffix of ω allowing to uniquely identify the relatedobject. This means that when ωid is sufficient toidentify an object with no ambiguity, it will be adoptedas the object full name, that is in our example ω =ωid. Moreover, to refer to a component o sub-part ofa structured object, e.g. ω�, we’ll use the “.” notation,e.g. ω�.{acc} means the set {acc} of ω�.

Tab. 1 lists the other elements in Eq. (2) with theirdefinitions (note that [· · · ] stands for optional and{· · · } means a possible empty set). In summary,the meaning of items appearing in the table is thefollowing:

• acc is a user or group account, possiblyrequiring remote authentication through ωaa,defined for object ω�.

• pp is a physical port (network interface). idpp

is the port unique identifier, while dla is adata-link address (e.g. MAC address: somenetwork interfaces, such as in firewalls, arenot assigned a data-link address), and {na}is a set of network addresses bound to dla.[w, [c], {ω}] is meaningful only for wirelessinterfaces: w means that the interface supports

65

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

Table 1: Implementation elements

wireless communications, [c] is the possiblecredential required to connect to the interface(i.e., access point), and {ω} is the set of roomobjects where the interface is accessible. Manysub-tuples 〈dla, {na}, [w, [c], {ω}]〉 are allowed.

• fr is a filtering rule, whose general formis based on the constitutive elements listedin the lower part of Tab. 1. A single rulefor a specific device may not include allelements in the table, and wildcards are alsoallowed. We will not discuss filtering rulesin more details in this paper, since we relyon Liu and Khakpour (2013) for the networkreachability computation. The general formatfor fr contains the union of fields needed tospecify rules for firewalls, switches and so on.Of course, given a particular device and/or rule,not all fields are either meaningful or neededand, in this case, we use the symbol “ ” todenote unused fields.

• sw describes an installed sw package bymeans of name and version.

• λ is a set of fully interconnected physical portidentifiers. A point-to-point link is described bymeans of two ports, whereas buses can haveseveral ports.

Object descriptions in Eq. (2) include operations. Ingeneral, any operation π� available on object ω� cantake one of the two possible forms:

π� ::= 〈π, {〈d, {c}〉}〉 (3)

π� ::= 〈π, {f}〉 (4)

Form (3) is used when the object, to which theoperation is bound, is a room or a physical container:π is the operation name, e.g. enter, whereas the

Table 2: Preconditions and effects f

set {〈d, {c}〉} describes all the doors which allowentering the room. {c} is the set of all credentialsthat are needed to open door d. The adoption ofa set is useful, in this case, to model situationswhere each user has his/her own credential to opena given door, besides circumstances where just onecredential is shared among all users. Moreover,different credentials can also be assigned to thesame door, depending on the direction it is actuallycrossed.

In analogy with form (3), form (4) describesoperations a user can carry out on devices and theirhosted resources. π is the operation name (e.g.,upload part program, start part program, admin),while f specifies both the preconditions and effectsof π on either the involved or (possibly) otherresources. Tab. 2 shows the f syntax, whereseven different and mutually exclusive kinds ofpreconditions can be specified. Their semantics is,informally, the following:

• phy acc [c] means that a user must be in thesame room as ω, i.e. have physical access to

66

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

ω, and own credential c (if specified) in order tobe able to perform π.

• loc acc ω′ : n′ [c] and local access ω′ : g′ [c]mean that, in order to perform π on ω, auser must already be active (e.g., logged) onsome object ω′, by means of either the user’susername n′ or the group g′ he/she belongs to.Note that preconditions may involve differentobjects. Moreover, when specified, credential cmust also be owned by the user.

• rem acc port [c] means that the operationcan be carried out by a user through aremote connection at either the network ordata link level. The user must own credential cwhen specified. It is worth noting that TCP/IPconnections are always established betweenlogical ports, but industrial systems ofteninclude special-purpose devices and softwarethat adopt communications at the data-linklevel. In the definition of port, lp is a logicalport whose unique identifier is idlp. pn is anoptional port number (e.g., 8080), na is thenetwork address (e.g., IP address), while pr isan optional protocol (e.g. Modbus).

• rem auth lp [c] means that a remote (possiblycentralized) authentication is needed. This pre-condition is used when π is a remote authenti-cation operation provided by an authenticationauthority ωaa listening on logical port lp.

• phy acc ∧ auth ω′ : n′: this logical and oftwo preconditions enables the correspondingoperation if the user is in the same room asthe object, and provided he/she has alreadybeen authenticated as user n′ by the remoteauthentication authority ω′, or he/she is able toauthenticate with ω′.

• rem acc lp ∧ auth ω′ : n′ this precondition issimilar to the previous one, but in this casethe object is remotely accessible through thelogical port lp.

The element post in Tab. 2 takes into account thepossible effect of the operation: in particular ω

′′: n

′′,

if specified, means that, by performing the operation,the user gains (local) access with username n

′′to

object ω′′

(e.g., the effect of the UNIX su operationon the login status).

For the purpose of investigating sequences ofvulnerabilities, we assume that D describes thestatic attacker’s environment, and denote with Tp theattacker’s state. Effects of actions performed by theattacker (i.e. access gained to a room, acquisitionof a logged status and so on) are then recorder inTp. Consequently, (D, Tp) is a representation of thesystem state.

Table 3: User’s state Tp

As mentioned above, the computation of all actions(and steps) carried out by any user in our modelhas to take into account the reachability of objectsin the network. However, as the way adopted forthe description of the network and its devices iscompatible with Liu and Khakpour (2013), weassume that the reachability of hosts and deviceswas computed in a previous step and stored ina suitable database, as the static view of thesystem enables us to do so. The following generalquery returns true or false as a result, dependingon whether or not a logical path exists and isactually enabled by the configuration of the networkinfrastructure:

∃ path(dlas, pns, nas, dlad, pnd, nad, pr, 〈ω, C〉) (5)

The meaning of dlas, pns, nas, dlad, pnd, nad

has already been introduced and shown in Tab. 1,whereas ω is the identifier of the room where therelevant object is placed and C are the (user’s)credentials exhibited to access existing wirelessnetworks (C).

Given a system model, described by means of theformalism introduced above, and a user who isassigned a set of credentials and is located in acertain room, we would like to compute all actions(and sequences of actions) that such a user canperform in the system. However, two elements arestill needed to make this goal successful, that isthe user’s state Tp and a suitable set of rules R.Tp is shown in Tab. 3: it includes the set LA ofall local accesses (i.e. active logged-in conditions)already obtained by the user, the current roomhe/she has reached and the set of credentials he/sheowns. The set of rules R defines and controlsinteractions between the user and the system.Indeed, elements of R are inference rules: theirformal specification can be found in Bertolotti et al.(2015) and is not reported here. Roughly speaking,a rule exists for any possible form of preconditionf in Tab. 2. Moreover, two additional rules allowthe user respectively to move from room to roomand to manage the exploitation of vulnerabilities inthe system (note that this latter rule is not definedin Bertolotti et al. (2015) but is detailed in thefollowing).

Each rule has an associated set of preconditions,that is logical predicates acting on both the systemmodel and the user’s state. When predicates are

67

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

satisfied for some triple (user, object, operation)1,the operation and object elements are recorded ina suitable way, and the postconditions of the rule areapplied, i.e. the user’s state is updated accordingly.In practice, the new user’s state can change allpreconditions of other rules to true and so on, so thatsequences of actions can be easily computed. Thisis why both the system model D and the user’s stateTp appear as arguments in all inference rules.

3. VULNERABILITIES

Several databases, which are publicly accessibleonline, contain updated descriptions of knownvulnerabilities MITRE (a); NIST (NIST); OSVDB(OSVDB); Sufatrio et al. (2004) but, unfortunately,this information is not machine-readable, that isready to feed an automated software tool, becauseit is provided in textual, informal language. Theneed of a formal model suitable for this purposewas stressed in the past Maggi et al. (2008), anda solution was proposed to capture all meaningfulinformation for automated processing (the approachin Maggi et al. (2008) merged outcomes from theMovtraq Sufatrio et al. (2004) and OVAL MITRE(b) international projects). By applying some ideasborrowed from Maggi et al. (2008) to the formalismpresented in Bertolotti et al. (2015), we can saythat the preconditions of any vulnerability v canbe translated into a corresponding set of logicalpredicates. When all predicates hold for someobject ω� in the current system state (D, Tp), thenthe postconditions of v affect the system stateby changing it to (D, T ′

p ). This means that vpostconditions can lead to a new system state whereother preconditions are now enabled, thus allowingto analyze sequences of vulnerabilities. It is worthreminding that such an analysis enables the studyof effects caused by exploiting chains of knownvulnerabilities, while it is not able to discover new(unknown) flaws, i.e. zero day attacks.

As an example, let us consider the followingpreconditions, which are met very frequently invulnerability descriptions:

• remotely reachable(ω�, (D, Tp)) is true if thesystem state (D, Tp) allows the attacker toreach object ω� through a network connection;

• has program(sw name, ver, ω�, (D, Tp)) is trueif object ω� runs version ver of softwaresw name;

• usage link compromised(ω�, (D, Tp)) is true ifthe attacker is authenticated and logged on

1in this case some means that these entities are considered asvariables to be bound to instances able to make the relevantpredicates true.

some object (host), and such an authenticationallows him/her to do some action / exploit someservice on the reachable object ω�;

• locally exploitable(ω�, (D, Tp)) is true if theattacker is logged on object ω�.

The main postcondition of interest forour purpose is also the most common:gain privilege(root, ω�, (D, Tp)), states that theattacker gains root (unlimited) privileges on objectω�.

The simple elements discussed above enablesthe description of real vulnerabilities such as thefollowing (vulnerabilities are identified by means oftheir CVE MITRE (a) id):

CVE-2006-0058: vulnerability affecting thesendmail program. The affected versions are:8.13.0,8.13.1,. . . ,8.13.5.

An attacker able to exploit this vulnerability canexecute arbitrary code on the affected node, thus hegains some kind of privilege on the node.Formal precondition set:{remotely reachabel(ω�, (D, Tp)),has program(sendmail, 8.13.1, ω�, (D, Tp))}Formal postcondition set:{gain privilege(root, ω�, (D, Tp))}

CVE-2007-0213: vulnerability affecting the MSExchange program. The affected versions are: 2000sp3, 2003 sp1, 2003 sp2, 2007. An attacker able toexploit this vulnerability can execute arbitrary codeon the affected node, thus he/she gains some kindof privilege on the node itself.Formal precondition set:{remotely reachabel(ω�, (D, Tp)),has program(MS Exchange, 2007, ω�, (D, Tp))}Formal postcondition set:{gain privilege(root, ω�, (D, Tp))}

CVE-2007-0027: vulnerability affecting the MSOffice Suite (2000,2002,2003 versions). Inparticular the Excel software is flawed: when afile containing a malformed IMDATA record isopened in Excel, system memory can be corruptedin a way that may allow an attacker to executearbitrary code.Formal precondition set:{usage link compromised(ω�, (D, Tp)),has program(MS Office, 2002, ω�, (D, Tp))}Formal postcondition set:{gain privilege(root, ω�, (D, Tp))}

CVE-2004-1235: vulnerability affecting the Linuxkernel 2.4 through 2.6.10. It allows local users toexecute arbitrary code by manipulating the VMAdescriptor.

68

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

Figure 2: Structure of the industrial network

Formal precondition set:{locally exploitable(ω�, (D, Tp)),has program(Linux kernel, 2.6.10, ω�, (D, Tp))}Formal postcondition set:{gain privilege(root, ω�, (D, Tp))}

The exploitation of any vulnerability mentionedabove can be managed through a suitable inferencerule whose predicates and postconditions are thesame as the vulnerability formal sets.

The extension of the analysis framework Bertolottiet al. (2015) to include the study of vulnerabilitiesrequires a suitable adaptation of the syntax derivedfrom Maggi et al. (2008) to fit in well with the model.Let us informally define the following action

ω��(dla, na) (6)

which returns a pair consisting of a datalink addressdla and a network address na such that na is boundto dla for some physical port of ω�.

Formal definitions for the vulnerability preconditionsare then the following:

remotely reachable(ω�, (D, Tp)) ::=

∃ω�s ∈ D.Ω | (ωs, n)[: (ωaa, naa)] ∈ ω�

s .{acc}∧(ωs, n)[: (ωaa, naa)] ∈ Tp.LA

∧

ω�s �(dlas, nas) ∧ ω��(dla, na) ∧

∃ path(dlas, , nas, dla, , na, , 〈Tp.ω, Tp.C〉)

has program(sw name, ver, ω�, (D, Tp)) ::=(sw name, ver) ∈ ω�.{sw}

locally exploitable(ω�, (D, Tp)) ::=(ω, n)[: (ωaa, naa)] ∈ ω�.{acc} ∧(ω, n)[: (ωaa, naa)] ∈ Tp.LA

gain privilege(root, ω�, (D, Tp)) ::=(ω, root) added to Tp.LA

The usage link compromised(ω�, (D, Tp)) is similarto remotely reachable(ω�, (D, Tp)) but also requiresthat the user be remotely logged with the sameaccount which enables the execution of someoperation on ω�.

4. EXAMPLE

Fig. 2 shows the simple network used to show howour technique works. Since we are interested inproving the feasibility of the proposed approach weselected the same example presented in Cheminodet al. (2009), irrespective of whether it mightnot represent a real threat today because ofthe presence of very old software versions andthe existence of widespread updates. The mainmotivation is that the adoption of the same exampleenables comparisons of the two approaches alsoin terms of computational complexity, besides theprecision of results. For sake of conciseness onlynodes and devices actually needed in the discussionare explicitly taken into account in Fig. 2. Thesubnetwork protected by firewalls fw1 and fw2represents a demilitarized zone (DMZ) containingcompany servers that are directly accessible fromthe outside world, i.e. with public IP addresses.Company internal hosts, either servers or desktopcomputers, are located between firewalls fw2 andfw3. These devices have private IP addresses andfw2 performs suitable address translations (NAT).A rather common architectural solution adopts twodifferent mail servers: access to the corporate(internal) server ims is more protected with respectto the external server ems, which is simply used torelay emails to ims. The field (control) network is

69

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

Figure 3: Description of hosts

protected by firewall fw3 and host computers plcin this area are soft programmable logic controllers(PLCs) running real-time applications under controlof a conventional operating system. A server aaacting as a central authority authenticates domainusers to access domain services. The managementhost m is needed to interact with soft PLCs andprovides some services, including network-wideproductivity tools for other hosts (not visible in thepicture).

Let us assume that all firewalls and switches areproperly configured in terms of addresses, ports andprotocols, so as to enable the expected legitimatetraffic flows, and neglect their corresponding formalmodels. We only focus on those elements of thehost models that are needed to describe a possibleattack. To keep the example small, all objectsare located in the same room W: this simplifyingassumption does not offer too much power to anexternal attacker, since no operation is allowed inthe system requiring a physical access precondition,except for the node where the attacker is actuallylogged on. Moreover, let us take into account anyinstalled software package only if it can play somerole in the attack, and assume that a remote node iexists where an attacker can log on and start his/heroffensive against some company critical device, thatis a soft PLC in particular.

Fig. 3 shows the formal description of all hosts inFig. 2 by using the syntax introduced in equations(2) and (4) and Tab. 1 and 2. As all hosts areplaced in room W (ωpath = 〈W 〉), prefix W : has

been omitted everywhere in the picture, and pathnames are shrunk to host names without any risk ofambiguity. The meaning of the specification in Fig. 3is informally the following:

• i is the host where the attacker can log in tostart his/her malicious activity. After physicallyaccessing i, he/she carries out the loginoperation and acquires root privileges since iis under full control of the attacker. The hostis equipped with a network interface and hasMAC and IP addresses.

• aa is the domain central authority for authenti-cation. It support the auth operation to authen-ticate remote users (rem auth precondition),i.e. users who either log in on remote hosts,or connect to servers belonging to the domain.The authentication server accepts requestsreceived through logical port lpaa configuredwith proper attributes and bound to networkinterface ppaa. If the connecting user knowscredential c (that is he/she has got c in his/hercredential bag Tp.C) he/she is successfullyauthenticated by aa with username n andgroup g.

• ems is the external mail server which supportsthe mail operation. mail is remotely exploitable(rem acc precondition) by connecting to logicalport lpems, bound to the ppems interface.Usually, email relaying services do not requirecredentials (the server accepts all incomingmessages, possibly discarding malformed

70

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

packets, and dispatches them to proper recipi-ents). An administrative account (root, adm) isdefined for ems, but attacks based on its directexploitation are not considered in this example.By contrast, the existence of such an accountis leveraged by the attacker by means of vul-nerability CV E−2006−0058 affecting the soft-ware sendmail, version 8.13.1 installed on ems.

• ims offers conventional mail services(MS Exchange version 2007) by receivingrequests through the proper logical portlpims, bound to the ppims interface. Theservice is not protected by any kind ofcredential/authentication mechanism: firewallsfw1 and fw2 ensure that only messagescoming from legitimate hosts, i.e. ems andinternal clients, can reach it. A login operationfor general purpose activities is allowedthrough domain authentication: the user hasto connect to logical port lpm1 from a remotehost. The login operation is successful wheneither the user has already been authenticatedwith account n on the remote host by the aaauthority or he/she performs a preliminaryauthentication step with aa . If everythingproceeds smoothly, the user is logged in onims, and (ims, n) : (aa, n) is added to his/herbag of gained accesses Tp.LA.

• m supports a login operation similar toims, and a runOffice service (packageMS Office, version 2002 installed), which canbe invoked by users (already) authenticated inthe domain. The user does not gain any loginstatus on m through the service invocation.

• plc runs a Linux distribution with kernelversion 2.6.10 and offers a conventionallogin service to the domain users. Alsoin this case, the user gains a logged instatus (plc, n) : (aa, n) in case of successfuloperation.

4.1. A possible attack sequence

Let us assume that the attacker is in room W at thebeginning, and both his/her local access (logged instatus) and credential bags are empty, i.e. Tp.C =Tp.LA = ∅. With the exception of i, which is underthe attacker’s control, all hosts enable operationsthat can be exploited only remotely. In practice,this means that neither actions can be immediatelyinvoked by the attacker, nor he/she is logged in onany node. Then the only initial step allowed is thelogin operation on i, whose successful completionchanges Tp.LA to {(i, root)}.

The attacker is now able to exploit remoteconnections, but firewall configurations only allow

him/her to reach the ems server. However, this isenough since ems runs sendmail version 8.13.1affected by vulnerability CV E − 2006 − 0058.Vulnerability preconditions are unfortunately metand let the attacker gain root access on emsand bypass any authentication mechanism. Tp.LAbecomes {(i, root), (ems, root)} and the attacker canget control over a host internal to the companynetwork.

Remote network connections from ems to imsare allowed by firewall fw2, and this is what theattacker needs to exploit vulnerability CV E − 2007−0213 affecting a remotely reachable host runningMS Exchange version 2007. In brief he/she getsunlimited rights on such a host. Root privilegesallow the attacker to impersonate any user (account)defined there, and inherit all rights and permissionson the same node. For this reason, Tp.LA is now{(i, root), (ems, root), (ims, root), (ims, n) : (aa, n)}.

Host m supports remote executions of itsMS Office version 2202 application by domainauthenticated users. The attacker, thanks to thedomain logged in status gained by conqueringims, is so able to run MS Office via theconnection between ims and m. Preconditions ofvulnerability CV E − 2007− 0027 are true and he/sheacquires root privileges on m too. Tp.LA becomes{(i, root), (ems, root), (ims, root), (ims, n) :(aa, n) (m, root), (m, n) : (aa, n)}.

Firewall fw3 is configured to let domain users loginin on plc remotely from m, and the attacker is ableto do so. It is worth noting that this is not a kind offlaw, but rather the use of a legal system mechanismthat the attacker can access thanks to a sequence ofexploited vulnerabilities. Sophisticated attack pathscan often leverage legal system mechanisms topursue the attacker’s malicious goal. When he/shegets logged in on plc as domain user n Tp.LA be-comes {(i, root), (ems, root), (ims, root), (ims, n) :(aa, n), (m, root), (m, n) : (aa, n), (plc, n) : (aa, n)}.

The final step leverages vulnerability CV E − 2004 −1235, which is now exploitable since the attacker islogged on plc as domain user n. Tp.LA increasesagain: {(i, root), (ems, root), (ims, root), (ims, n) :(aa, n), (m, root), (m, n) : (aa, n), (plc, n) :(aa, n), (plc, root)}, and the attacker reaches itsgoal.

5. CONCLUSIONS AND FUTURE WORK

Analysing the combined effects of known vulnerabil-ities in large and complex networks is an importantissue to grant the whole system an adequate level ofsecurity against attacks. This aspect is even crucial

71

Analysis of Exploitable Vulnerability Sequences in Industrial Networked Systems: A Proof of ConceptsCheminod • Durante • Seno • Valenzano

when industrial networked systems are considered,because in many situations changes and patchescannot be applied systematically to cope withsoftware and hardware flaws as they are discovered.Indeed, peculiarities and requirements of manyindustrial scenarios such as 24/7 availability or non-interruptibility of critical process control systems,prevent the methodic adoption of countermeasuresand lead to tolerate the presence of vulnerabilitieswhen they are recognized not to be exploitable forthe security of the actual system. Unfortunately, thecombined effects of vulnerabilities, which are notconsidered harmful when isolated, can give riseto attack paths that can be leveraged by malicioususers to undermine the system.

This paper has dealt with the automated detection ofsuch dangerous sequences of known vulnerabilities.In particular we have shown how an analysis frame-work we previously developed for the verificationof access control policies in industrial networkedsystems can be suitably extended to study vulner-ability sequences. In particular, we have discussedrequired changes to the formal model adopted inthe analysis and introduced some additional ele-ments in terms of preconditions and object attributesthat are needed to manage vulnerabilities in theimplementation view of the modelled system. Futurework will focus on the complete formalization of theproposed approach and on the development of anautomated analysis software tool derived from theanalyzer already available for access control policies.

REFERENCES

Cheminod, M. et al. (2009) Detecting chains ofvulnerabilities in industrial networks. IEEE Trans.Ind. Inform., 5 (2), 181–193.

Cheminod, M., Durante, L., and Valenzano, A.(2013) Review of security issues in industrialnetworks.IEEE Trans. Ind. Inform., 9 (1), 277–293.

Bertolotti, I. C. et al. (2015) A twofold model forthe analysis of access control policies in industrialnetworked systems. Comput. Stand. Interfaces, Toappear.

Granzer, W., Praus, F., and Kastner, W. (2010)Security in building automation systems. IEEETrans. Ind. Electron., 57 (11), 3622–3630.

Lin, M. et al. (2009) Static security optimization forreal-time systems. IEEE Trans. Ind. Inform., 5 (1),22–37.

Liu, A. and Khakpour, A. (2013) Quantifyingand verifying reachability for access controllednetworks. IEEE/ACM Trans. Netw., 21 (2),551–565.

Ma, Z. and Smith, P. (2013) Determining risks fromadvanced multi-step attacks to critical informationinfrastructures. In: Proc. 8th International Work-shop on Critical Information Infrastructures Secu-rity (CRITIS), 142–154.

Maggi, P., Pozza, D., and Sisto, R. (2008) Vulnerabil-ity modelling for the analysis of network attacks. In:Proc. 3rd International Conference on Dependabil-ity of Computer Systems (DepCoSRELCOMEX),15–22.

MITRE. Common vulnerabilities and exposures(CVE). Bedford, MA: The MITRE CorporationAvailable from http://cve.mitre.org/

MITRE. Open vulnerability and assessment lan-guage (OVAL). Bedford, MA: The MITRE Corpora-tion Available from http://oval.mitre.org/index.html

National Institute of Standards and Technology.National vulnerability database (NVD). Availablefrom http://nvd.nist.gov/

OSVDB. Open source vulnerability database (OS-VDB). Available from http://osvdb.org/

Shakshuki, E., Kang, N., and Sheltami, T. (2013)EAACK - A secure intrusion-detection system forMANETs. IEEE Trans. Ind. Electron., 60 (3),1089–1098.

Sufatrio, R., Yap, H. C., and Zhong, L. (2004)A machine-oriented integrated vulnerability data-base for automated vulnerability detection andprocessing. In: Proc. 18th USENIX Systems Ad-ministration Conference (LISA), Symantec. Secu-rityFocus Vulnerability Database, 47–58. Availablefrom http://www.securityfocus.com/vulnerabilities/

72