Hacking the Smart Grid
Information in this chapter:
Now that we have an understanding of Smart Grid architecture (see Chapter 2) and we can start examining Smart Grid attack methodology. Depending upon the motive of the attacker and the target of the attack, the exact methods of attack may vary. Understanding the motives of the attacker and the inherent vulnerabilities of the systems helps to determine exactly how an attacker might approach, assess, and breach a Smart Grid. As with any cyber attack, there are well-defined steps to hacking a Smart Grid. Starting with reconnaissance and then scanning, the architecture of the grid can begin to be mapped—the aid of open-source intelligence can greatly simplify this important first step. Then—once a target system is identified—enumeration, penetration, and infection occur. Once breached, the attacker can continue to enumerate and propagate, spreading the infection among any or all interconnected systems, or use these systems to “pivot” into other isolated systems. Because some of the prime targets of a Smart Grid cyber attack include data residing in back-office or control room systems, it is often the blended attack that is of the most concern.
Motive
Because a Smart Grid is so complex and diverse, cyber attacks against the Smart Grid are most easily classified by their intent. The most common motives for a cyber attack against a grid infrastructure are the theft of information for profit or reconnaissance, and denial of service, either as a means to sabotage the grid itself, or to impede the business processes of the operator, which could be part of a much larger blended attack. By looking at attacks by motive rather than attack process, a broader risk assessment can be determined. Similarly, remediation of those risks can occur at a higher level, by attempting to eliminate motive as the first step in a broader effort to protect against specific attack methodologies (see “Attack Methods” later in this chapter).
For example, if personal and financial information about consumers is accessible from the advanced metering infrastructure, threats against AMI can be disincentivized by isolating, encrypting, or otherwise disassociating this target data from the AMI infrastructure.
Theft of information
There is a lot of valuable information housed within the nebulae of a Smart Grid. Personal information about Smart Grid consumers—such as finance and billing information—is available from CRM and billing systems, for example. Similarly, information about energy consumption can be obtained from the advanced metering infrastructure and from other components of the Smart Grid and used to derive additional personal information. The privacy risk of the Smart Grid is considerable enough to justify a more in-depth discussion in Chapter 4, “Privacy.”
In addition to personal information, the SCADA and automation systems within the grid also provide a blueprint to the inner workings of the grid operations. This is valuable intellectual property that could be used for malicious purposes ranging from the influence of energy trading to the development of a targeted, weaponized attack against the grid infrastructure or against the grid operator and/or their customers.
Denial of service
One of the most basic attacks remains the denial-of-service attack. In today’s networks—with high-bandwidth, high-performance end systems, and modern operating systems—a denial-of-service attack can require some orchestration. Even something as simple as oversubscribing a network interface can present scalability issues. Distributed denial-of-service attacks, where large number of infected systems are used in a coordinated attack, are necessary in many cases. When the systems are publically facing, such as a corporate web server or VoIP service, attackers can easily rise to this challenge by spreading malware as prolifically as possible through the Internet. With millions of home computers connected to dedicated broadband Internet access, the resources at an attacker’s disposal are virtually limitless.
Once again, however, the Smart Grid—especially the SCADA and industrial control systems used within the Smart Grid—is different. Ideally, they are not (supposed to be) publicly accessible, which is an added obstacle to an attacker; at the same time, they are also not “modern” systems—many are running outdated and unpatched operating systems, over lower-bandwidth networks, and supporting real-time and very fragile industrial protocols.
The nature of many Smart Grid systems, therefore, makes them much more susceptible to a denial-of-service attack. All attackers need to do sufficiently influence the network—injecting traffic, performing an aggressive scan, or even something as simple as duplicating an existing IP address—and they can potentially interrupt that service. One attack, presented at the Digital Bond S4 conference in 2010 used a simple wireless jammer to cause an 802.11 discovery cascade to disrupt industrial systems.1 The attack didn’t target the ICS at all, but rather the networking infrastructure around it, knowing that the result could accomplish the same goal.
The Smart Grid complicates this scenario by combining the relative fragility of SCADA and ICS systems with an attack surface that rivals the Internet itself. However, unlike the Internet, security measures implemented to protect this network will typically reside in the hands of the grid operator and not an experience service provider (ISP). Therefore, it is now possible to choreograph distributed attacks against these critical communications systems. This could pose particular risks to substation automation systems, where distributed denial-of-service attacks are perpetrated inbound over long-range wireless frequencies, or even through the advanced metering infrastructure. Where cellular connectivity is provided (such as is common for Smart Meters) war-dialing attacks could be used as a denial-of-service attack against the metering infrastructure. For field devices within the distribution system, cellular, satellite, and radio, vectors could be used.
Because the “service” of a Smart Grid is ultimately the delivery of energy, manipulating the systems within the Smart Grid can cause an outage—such as spoofing a GPS time source to bring a line out of phase and trip protection circuits, or faking an outage to trick an EMS into routing power around a service area—to effectively create a “denial of service” of energy. In other words, rather than a traditional DoS or DDoS, we have a manipulation of service that prevents utility service to the end user. For example, by manipulating demand load measurements, it could appear that less power is required in a given area than what is actually needed. This could cause service to be re-routed elsewhere, and potentially bring down swing units—effectively causing a brownout and general grid instability in a target area.
Manipulation of service
The difference between denial of service and manipulation of service is subtle but important. Where denial-of-service attempts to make a network or device unavailable to its operators, the goal of a manipulation of service is to preserve the availability of a service while effecting or altering its operation. Rather than preventing the service from functioning at all, it manipulates it. Examples of manipulation of service include very simple attacks, such as spoofing GPS time synchronization to de-synchronize distribution phasor readings, to very complex attacks, such as the St****t attack, which penetrated and altered the specific control instructions in both SCADA and ICS field systems—the same types of systems used in substation automation, distributed generation and other Smart Grid systems.
Because the Smart Grid is built upon a foundation of real-time measurement within and between many interconnected systems, manipulation is often as easy as the example above: a particular measurement is altered to impact whatever system(s) rely upon that data (this is covered in more detail below under “Setting Phasors to Kill”). Examples of manipulated data and the systems that the attack could impact are provided in Table 3.1.
Note that the manipulation of some data sources could be catastrophic: by manipulating the low-and high-voltage sides of a transformer (either by directly or by tricking an operator or automated program by providing false measurements), an arc condition can quickly overheat coils, boil the mineral oil used as insulation, and cause a massive explosion. Other results could be relatively benign, such as billing errors, or the dispatch of a field services crew to repair a “good” line that is being measured as “bad.” In a study of transformer failures by the International Association of Engineering Insurers, research shows that nearly 15% of transformer failures in a year are attributed to overloading, improper operation, or surges2—all of which could occur as the result of manipulated energy system measurements.
Identifying a target
One of the first steps in a cyber attack is to identify a target. Because of the complexity of the Smart Grid and the many interconnected systems that comprise it, there are many targets to choose from, and many systems that could be targeted as a beachhead with which to reach additional targets. Table 3.2 lists several primary and secondary targets, as derived from NISTIR 7628 Infrastructure diagrams. Please note that this list is far from complete: it is intended to highlight the number of systems that can be used as targets and attack vectors throughout the Smart Grid.
The interconnectedness of the Smart Grid is a particular challenge because of the potential ability for an attack to propagate easily between them—therefore almost any system becomes a viable target for attack. This is especially concerning when you can draw a line from a customer’s in-home EMS, through the Distribution Management System, to T-SCADA systems all the way to the Bulk Energy Control System and G-SCADA. This large-scale distribution of systems makes it challenging to effectively segment these systems resulting in an architecture that makes is relatively easy for an attack to move between systems. It is therefore equally as important to manage and (where possible) mitigate “horizontal propagation” through the use of compensating security controls and countermeasures (see Chapter 6, “Securing the Smart Grid”).
If any one of these target systems is connected to the Internet, of course targeting these systems becomes easy, which is why every major cyber security standard, regulation, or guidance document recommends that systems are never connected directly to a public network. While private or leased-line WANs are increasingly uncommon, the use of Virtual Private Networks (VPNs) over the shared WAN communications infrastructure (aka public networks) provides appropriate transport layer security and access controls. However, as recently as February 2012, the ICS-CERT released a report on the increasing threat to industrial control systems, citing the primary causes of concern as “… Internet accessible ICS configurations, vulnerability and exploit tool releases for ICS devices, and increased interest and activity by hacktivist groups and others.”3 The report went on to clearly state its intent “to inform critical infrastructure and key resource (CIKR) asset owners and operators of recent and ongoing activity concerning increased risk to CIKR assets, particularly Internet accessible control systems.”3 Unfortunately, this guidance is necessary as ICS components in many industries continue to be insufficiently protected from Internet access. Combined with Internet search tools such as Shodan, which help identify Internet-connected devices by the services that they use, these devices are not only easy to hack, but also they are easy to find.
If systems are properly removed from the Internet, more traditional scanning will be needed to locate targets. However, in the Smart Grid, nothing is as easy as it seems. A SCADA server, a Phasor Data Concentrator (PDC), a recloser or some other Smart Grid device may be connected to an industrial grade Ethernet switch, segmented behind a router, a firewall and maybe even an Intrusion Prevention Systems (IPS). However, things get more difficult in the Smart Grid because there is a good chance that a purpose-built device will also utilize long-range or even global wide area network connectivity as a means of distribution communications or synchronization—such as a phasor measurement unit (PMU)’s C37.118 protocol, GPS-based network time protocols, satellite, microwave, radio, mesh wireless, and others. Further complicating things, we see a proliferation of devices utilizing integrated remote access servers in order to make it “easier” for technicians to obtain remote access to substation or field devices. While the business justification is sound (it is costly and time consuming to send technicians into the field when an issue could be resolved remotely), these systems become strong pivot points for cyber attacks. The easily accessible networks (wireless) are used to exploit the device, gain root, or admin access, and then use that device as the launching point to other systems—including other devices on the wired, wireless, and even serial networks. In other words, the entire system is at risk of compromise via the weakest component in the extensive, composite architecture.
So, while common attack methodologies apply to the Smart Grid—scan for a target, enumerate the target, identify vulnerabilities, and then exploit those vulnerabilities—the attack surface is much larger, and the number of inbound attack vectors is high. In addition, when application-layer protocols are used over TCP/IP, additional tricks can be used to identify and enumerate the participants in those protocols.
Scanning transmission and distribution infrastructure
Depending upon the nature of the target, the steps required to scan a Smart Grid target may require little if any variation from the standard hacking playbook, or they may be able to leverage scanning and enumeration techniques that are specific to world of SCADA and industrial controls. For example, if a T-SCADA server or gateway is built using commercial off-the-shelf components and a standard Windows OS, these systems can be easily identified using Nmap, enumerated via a vulnerability scan, and exploited using any number of relevant exploits within the Metasploit framework. If the target is running SCADA software, performing any sort of process automation, or communicating using a known industrial control protocol, there may be additional steps that can be taken to scan and enumerate deeper into the industrial control environment. In the context of the Smart Grid, this means that substation automation servers can be used to enumerate field devices, protection systems, and other devices, potentially mapping the entire grid.
To recap common scanning techniques, a tool (such as Nmap) is used to discover all endpoints on a TCP/IP network. Scanning a network typically begins with broad attempts to identify network devices and hosts using a ping sweep and then leveraging additional capabilities of the Internet Control Message Protocol (ICMP) to determine additional information, such as the network mask (which allows you to derive subnet information), open TCP and UDP ports (which allows you to identify operating services, as most services map to well-known ports). In industrial networks, network scanning works in much the same way. However, the results of the scan can indicate if the device is a SCADA or process control device by looking for common ports: port 102 is used by IEC 61850 messaging, C37.118 uses 4712 and 4713, 502 is Modbus TCP, 530 is RPC, 593 is HTTP RPC, 2222 or 4818 is Ethernet/IP, 4840 or 4843 indicates OPC UA over TLS/SSL, port 20000 is used by DNP3, ports 34,962 through 34,964 are used by Profinet, etc.4
So if you see a device communicating on port 502, it can be inferred that it is using Modbus TCP, and if you see ports 2222 or 44818, that the system is using the Common Industrial Protocol (CIP) over EtherNet/IP. Data seen on port 102 can be assumed to be substation automation controls or messaging, while port 4713 can be assumed to be a PMU measurement. It can be further inferred that a device using these ports as well as common “enterprise” ports and services like HTTP is a SCADA system, HMI, controller or other industrial control system asset.
With this knowledge, the scanning can continue at another level, using the identified industrial network protocol to further investigate the system. This works because most industrial protocols used in the Smart Grid and other control environments are based on a client-server messaging model. These models require that requests and acknowledgements be sent between devices, including information about the clients, their operating state, values within their registers (such as a phasor reading from a PMU or a power consumption reading from a smart meter), etc. It is therefore possible to perform a DNP3 request sweep in the same way that you perform a ping sweep. The requests solicit responses from active clients, identifying all of the DNP3 clients within the system.5
Again St****t has exemplified, the disruptive potential of this type of scanning. Once the St****t payload establishes itself into the Siemens PCS7 system, it was able to enumerate the Profibus devices remotely via the S7 communications driver, allowing it to “listen” to its surroundings and adapt accordingly. In the case of St****t, malicious code was only written to the PLC once a specific target device was identified, which it achieved by looking at the device identifiers within the Profinet packets. Profinet, like all industrial protocols, is used to communicate values and commands to these devices, so listening to the protocol can also determine the specific operational settings of that device.6
Today, it’s easy. There are SCADA-specific scanning modules available within the widely used Nmap and Metasploit framework tools. On September 17, 2012, python code was made available online via https://code.google.com/p/plcscan/, providing a dedicated scanner for Modbus and S7 devices. These auxiliary modules simplify the fingerprinting of SCADA devices, directly from within the same tool that provides enumeration and exploit modules targeting those same systems. While not all inclusive at the time of this writing (at this time, there are 32 SCADA-specific exploit modules within Metasploit as well as 108 Nessus plugins to assess SCADA components for known vulnerabilities), the presence of such tools is indicative of a growing trend. SCADA and ICS systems used within the Smart Grid or other industries can no longer assume “security by obscurity,” as the efforts of both black hat and white hat security researchers focus more heavily on industrial control. While researchers are still, for the most part, focusing their attention on the Windows-based platforms typical of the Server and HMI components, more and more research is shifting to the embedded controllers and endpoints that typically utilize non-Windows components.
Leveraging automation systems for enumeration
The protocols used by substation automation systems can also help to enumerate a target. Substation automation is, essentially, a function of T-SCADA and D-SCADA, utilizing the same protocols discussed above. This approach was used by a Project Basecamp researcher to enumerate an EtherNet/IP system. By capturing and analyzing CIP traffic, detailed knowledge about the device can be extracted from the CIP, including vendor and object identifiers, service requests, and more.7 Basecamp was performed in a laboratory, with a known target device and readily available documentation, but the same process could have been performed to enumerate a device communicating on port 2222, as discovered by an Nmap scan.
Each industrial protocol utilizes its own function codes, and some proprietary function codes may be used on specific devices (necessitating some reconnaissance). However, by obtaining the vendor and device IDs, it is possible to research the exact device. In many cases, specific functions are documented online. In other instances, specific ICS devices have known vulnerabilities, and perhaps even exploit code—all available on the Internet. It should be noted that, while documentation typically exists for “open” protocols, the encryption or obfuscation of these protocols is often used by vendors. The resulting vendor-specific proprietary protocols—including the S7 protocol by Siemens, Honeywell’s Control Data Access (CDA) protocol, and others—retain a somewhat greater degree of obscurity. These protocols are still susceptible to attack, however, despite efforts to maintain obscurity, additional efforts to obtain information about the protocols may be necessary.
Vulnerability
Once a target has been identified and enumerated within the Smart Grid, there are several specific attack methodologies that can be used to penetrate key systems, often by exploiting vulnerabilities in the same SCADA and control protocols used by transmission and distribution management systems, substation automation, EMS,etc. Some of these vulnerabilities are specific to a device and require effort to identify and exploit. However, more and more Smart Grid systems are being analyzed and a growing number of disclosed vulnerabilities against these systems are being made publically available—often with corresponding exploit code. Worse still, as is the case described above, there are certain “vulnerabilities” that are inherent within the protocols used by these systems. These are not bugs or unintentional vulnerabilities that are the result of bad coding. They are simply the result of a command and control protocol that is functioning as designed. Unfortunately, this means that these vulnerabilities cannot be easily resolved because they are not specific to a single product or even vendor. To fix an inherent insecurity with a protocol like Modbus, for example, it would require significant re-engineering of the protocol itself, which in many cases would require a coordinated multi-vendor industry effort. While some organizations have done this—such as OPC UA and OPC XI, two variations of a “secure” OPC implementation—there is the added challenge of adoption. Similarly, the IEC has made efforts to secure substation infrastructures via the IEC 62351 standard, which recommends secure transport methods for TCP/IP-based substation communications. However, even if a protocol is made secure, the large installed base of legacy devices using the legacy protocols will ensure that many vulnerable systems will remain in the field, waiting to be exploited. Regardless of whether the vulnerability is product specific or inherent in the protocol operation, a vulnerability within the Smart Grid infrastructure can be exploited in numerous ways, including Man-in-the-Middle and network replay attacks. If a server is rooted, any variety of payloads can be executed within the Smart Grid.
Devices-specific vulnerabilities
Many Smart Grid devices possess vulnerabilities that can be determined through analysis and reverse engineering of that device. For example, by utilizing a variety of open source development and debugging tools a specific device can be fully analyzed—from surface vulnerability testing to code extraction, decompiling, and reverse engineering. The goal is to identify weaknesses in the development such as heap or stack overflows, which could allow malicious code to be executed by the target system. Many white hat tools and agencies exist to facilitate this process, such as Wurldtech Security Technologies, makers of the Achilles Test Platform, and the ISA Security Compliance Institute (ISCI). Achilles is a purpose-built testbed for the analysis of real-time and embedded devices using protocols including GOOSE (IEC 61850 messaging), RPC, EtherNet/IP, MODBUS/TCP, ZIGBEE (widely used in advanced metering and other in-home systems), OPC UA, and others.8
Again, the Basecamp disclosures of early 2012 included several device-specific vulnerabilities, resulting in several published exploits that can be used to target specific Smart Grid devices. From the banner of one such auxiliary Metasploit module:
# This module implements a CLI backdoor present in the General Electric D20 Remote Terminal.
# Unit (RTU). This backdoor may be present in other General Electric Canada control systems.
# Use with care. Interactive commands may cause the TFTP server to hang indefinitely, blocking.
This module and others like it makes security assessment within a control environment easier, but also provides a powerful tool to attackers. As mentioned earlier, there are currently freely available Metasploit modules, NSE scripts for Nmap, dedicated scanning tools such as Modbus.py and other methods of Modbus scanning, enumeration, and exploitation.
Leveraging known vulnerabilities
Reverse engineering device code is an effective but resource-intensive method of identifying new vulnerabilities. For a large cyber weapon such as St****t, the use of zero-day vulnerabilities can ensure the successful delivery and execution of a malicious payload. However, in the post-St****t world, there are many well-known, fully disclosed ICS vulnerabilities. At the time of this writing, there are disclosed vulnerabilities for 3S, 7 Technologies, ABB, Advantech, AGG, Arbiter, ARC Informatique, AREVA, Atvise, Automated Solutions, AzeoTech, Beckhoff, Broadwin, Certec, Cisco, Cogent, COPA-DATA, Control Microsystems, Ecava, Emerson, Fultek, GarrettCom, General Electric, Honeywell, Intellicom, Iconics, Inductive Automation, InduSoft, Innominate, Invensys, IOServer, IRAI, Kessler-Ellis, Korenix, Koyo, Measuresoft, Microsys, Moxa, Ocean Data Systems, Open Automation Software, Optima, ORing, OSIsoft, PcVue, Pro-face, Progea, RealFlex, Rockwell Automation, RuggedCom, SafeNet, Samsung, ScadaTEC, Schneider Electric, Schweitzer, Sielco Sistemi, Siemens, Sinapai, SpecView, Sunway, Technomatix, Tridium, Unitronics, VxWorks, Wago, WellinTech, Wonderware, and xArrow.9
Many of these vulnerabilities have been exploited either in a proof of concept environment or through the development of actual exploit code, making it extremely easy for intermediate hackers to develop new attack variants against these systems. At the time of this writing, there are 32 SCADA-and ICS-specific exploit modules for Metasploit. Metasploit includes modules to exploit systems from 18 vendors, including large ICS vendors such GE, Rockwell Automation, Schneider, and Siemens. Some of these modules extend beyond a single vendor, such as the ControlLogix Ethernet/IP exploit disclosed by Digital Bond in February of 2012. This module exploits inherent vulnerabilities in the Ethernet/IP, and therefore potentially impacts any or all products using Ethernet/IP. The ODVA currently indicates that there are 285 member companies, clearly indicating the prevalence of the Ethernet/IP. In addition, a more recent disclosure of 3S Software Gmbh’s CoDeSys Control Runtime system could impact 261 additional ICS vendors and their controller products.10 Any of these systems, if used within the Smart Grid, represent a vulnerable attack surface, and a vector through which many aspects of the grid can be attacked.
Inherent vulnerabilities in industrial protocols
As mentioned, many industrial protocols are vulnerable by design: the protocols themselves are designed to provide command and control, and often lack any compensating measures (such as encryption or authentication) to limit how that command and control capability is utilized. In 2012, the control system cyber security consulting and research firm Digital Bond initiated Project base Camp, which in their own words is “a research effort by Digital Bond and a team of volunteer researchersto highlight and demonstrate the fragility and insecurity of most SCADA and DCS field devices, such as PLC’s and RTU’s.” The result was published vulnerability and exploit research against inherent vulnerabilities in General Electric, Schneider Electric, Koyo, Schneider Electric, Schweitzer Electronics, and Wago devices.11
Basecamp was and is a highly controversial project within the ICS cyber security community. According to Digital Bond, “Project Basecamp is attempting to be a Firesheep Moment for PLC’s. The team has, not surprisingly, found many vulnerabilities in the PLC’s, but perhaps more importantly have identified “insecure by design” issues that are actually much easier to leverage to affect the availability and integrity of a process …” The key to making this a Firesheep Moment for PLC’s is providing tools so any engineer, IT type, security professional, or anyone with a bit of computer skill can demonstrate just how fragile and vulnerable these PLC’s are. It’s beyond, PLC’s are vulnerable. Basecamp provides the tools to show an executive just how easy it is to take down the SCADA or DCS.”11
The “firesheep moment” is a reference to Eric Butler’s Firefox extension that enabled HTTP session hijacking: an event that immediately raised HTTP security concerns by putting the tools in the hands of the community. However, with the criticality of the target industries at stake, Basecamp was condemned by many in the community as an act of irresponsible disclosure due to the fact that it failed to consider the impact of these vulnerabilities to the customers who have them deployed within their industrial processes. At the same time, many cyber security firms close to Basecamp lauded its initiative and desire to promote action.
One such example specifically exploited the EtherNet/IP to control a Rockwell Automation ControlLogix system. However, it should be noted that it was not a ControlLogix vulnerability that was exploited, but the underlying protocol, and as such this exploit is highly relevant due to the prevalence of the EtherNet/IP in industrial control systems. Basecamp researchers used a variety of network monitoring and reverse engineering tools to identify EtherNet/IP functions and object identifiers. As a result, several attack methods were disclosed7:
• Forcing a system stop: By sending a CIP command to the device, this attack effectively shuts off the CIP service and renders the device dead. This puts the device into a “major recoverable fault” state.7
• Crashing the CPU: This attack crashes the CPU due to a malformed CIP request, which cannot be effectively handled by the CIP stack. Again the result is a ‘major recoverable fault’ state.7
• Dumping device boot code: This is a CIP function that allows an EtherNet/IP device’s boot code to be remotely dumped.7
• Reset device: This is a simple misuse of the CIP system reset function. The attack resets the target device.7
• Crash device: This attack crashes the target device due to a vulnerability in the device’s CIP stack.7
• Flash update: CIP, like many industrial protocols, supports writing data to remove devices, including register and relay values, but also files. This attack misuses this capability to write new firmware to the target device.7
• Note that the Flash Update attack identified under Project Basecamp loosely mimics the behavior of St****t, which wrote new logic to a Siemens PLC in a similar fashion using the Profinet protocol. Surprisingly, many of these types of attacks are possible across many other ICS protocols, as they represent predefined function codes within the protocol.
Another example of inherent vulnerability involves the rash of recent vulnerabilities within the Siemens Simatic system. The Simatic Step 7 system is an “integral component part of the centralized Totally Integrated Automation Portal engineering framework. Thanks to complete integration into the centralized engineering framework, SIMATIC STEP 7 V11 has a uniform operator input concept across all automation tasks with shared services (e.g. configuration, communication, diagnostics), as well as automatic data consistency.”12 So, the Totally Integrated Automation (TIA) framework, like many SCADA system architectures, provides configuration, communication, and diagnostic capability. The TIA framework is based upon International Organization for Standardization Transport Service Access Point (ISO-TSAP), a protocol based on RFC 793 (Transmission Control Protocol) and RFC 791 (Internet Protocol) that make up TCP/IP. ISO-TSAP is therefore easy to monitor, record and manipulate—up to including the engineering and injection of new packets.13
ISO-TSAP is plain text, subjects to overflows, and gives absolute control over the SIMATIC system, allowing a manipulated, replayed, or injected packet to manipulate the configuration, communication, or diagnostics capabilities of TIA. This essentially allows TIA to inject malware into a Siemens SIMATIC system.13
Because ISO-TSAP is clear text, important information about the devices, commands and the process as a whole can either be directly extracted or derived from monitored packets.13 Just as with EtherNet/IP, therefore, TIA can be used to obtain sensitive information such as:
Turning a vulnerably into a compromise
When a vulnerability is identified—either through reverse engineering or through the disclosure of a vulnerability by another researcher—it can be used to build a targeted exploit. Even if a disclosed vulnerability does not include sample exploit, information about the vulnerability can allow an attacker to craft an attack to compromise the target system. SCADAhacker.com illustrates this process using the seven-Technologies IGSS (Interactive Graphical SCADA System) platform. In early 2011, researcher Luigi Auriemma published a service vulnerability of the IGSS platform.14
The IGSS system like most SCADA system provides graphical representation of a process. The user interface of the console provides both monitoring and control capability, allowing the operator of the console to trip protection relays, step-up or step-down voltages, etc. It also provides access to the necessary engineering toolkits or Software Development Environment (SDE) to create new logic.15
The vulnerability disclosed by Luigi Auriemma includes proof of concept code that proves the vulnerability without any malicious effect. Specifically, the exploit proof of concept code uses the IGSS_8b.dat to send a packet that executes the calculator.exe tool, causing the calculator to open on the console server. While the POC is benign, it is possible to take this same vulnerability and craft a malicious payload that can be executed in place of calculator.exe. In the SCADAhacker.com example, the Meterpreter tool (part of the Metasploit framework), is used to generate a payload and also to drop this new payload onto the IGSS server. Once a new payload is in place, the IGSS_8b.dat sends a packet to execute the new payload—effectively infecting the target with malware using the same disclosed vulnerability.16
In SCADAhacker’s example, the payload is designed to establish a Meterpreter session to allow further exploitability via Metasploit. For example, Metasploit could be used to:
• Install callback malware, to establish persistence even a system is rebooted.16
• Scrape the server for credentials, providing hashes of all passwords, which can later be cracked or can be passed along as is to break further authentication.16
• Escalate privileges to provide greater control. Unfortunately, because many SCADA systems run as root or admin, full escalation can be achieved via a compromised SCADA system).16
• Create a remote VNC session to provide remote desktop access to the SCADA server providing unrestricted access to change configurations, alter operational graphics, and send commands to control devices.16
This last action effectively “pops the HMI,” bringing the human-machine interface capability of IGSS console to a remote hacker’s computer or laptop. Rather than launching a harmless calculator application, the vulnerability was used to obtain absolute command and control over the SCADA environment, where the attacker can do essentially anything he or she pleases.
Attack tools
There are many tools available, most of which are designed for use by security teams to test for and resolve specific vulnerabilities, or to perform in-depth security assessment tests. However, these same tools can easily be used by a malicious agent to facilitate all stages of a cyber attack. Most are well-known, general-purpose cyber security tools, although recently some Smart Grid specific tools have also been developed. It is important to become familiar with these tools and what they can do against the networks and systems of the Smart Grid.
General tools
Many commonly available tools are available to test for vulnerability and exploitability of digital information systems. Much has been written about tools such as Nmap for network scanning, the Social Engineering Toolkit (SET) for social engineering attacks, Nessus, Nexpose, and OpenVAS for host fingerprinting and vulnerability assessment, etc. In addition, frameworks for penetration testing and exploitation area also available. Metasploit, perhaps the best known exploitation toolkit, combines social engineering, scanning, enumeration, vulnerability assessment, and a variety of exploitation capabilities into a common framework. Metasploit includes several auxiliary modules for scanning and enumerating the systems used by generation, transmission, and distribution SCADA, making it particularly relevant to Smart Grid cyber security. Other penetration testing toolkits, such as Immunity’s Canvas framework, which also include SCADA exploits. Gleg Ltd., a Moscow-based security firm, maintains the Agora SCADA+ Pack for Canvas. This toolkit promises 100% coverage of public vulnerabilities, bugs, zero-day SCADA exploits, weak point analysis of SCADA, industrial PCs, smart chips, and industrial protocols.17 Nearly all of these tools and frameworks are available either as open-source or available in a “community” no-charge version.
Smart meter tools
Two tools are now available to hack smart meters through optical interfaces: SecureState’s “Termineter” and InGuardians’ “OptiGuard.” The former is open-source, extensible and readily available to anyone, while the later is being provided in a controlled manner to those who need it in the industry—primarily the smart meter vendors and their customers, who are trying to deploy more secure metering in today’s Smart Grids.
Both tools operate in a similar manner and leverage the use of optical diagnostics interfaces on most smart meters. These interfaces—designed to facilitate field crew activities at a home—combine the American National Standard Protocol Specification for ANSI Type 2 Optical Port (ANSI C12.18) and the American National Standard for Utility Industry End Device Data Tables (ANSI C12.19) to provide a common method for accessing predefined data tables within a smart metering infrastructure. ANSI C12.18 includes specifications for requesting information from a meter, identifying service parameters, reading and writing to a meter, logon and security specifications, and accessing meter table data.18 Meter data tables include a wealth of information, including information about meter identity, meter manufacturer, operating mode, configuration and status; measurements and measurement parameters of the meter; and a variety of diagnosticscapabilities including a variety of configuration and procedure commands.19
Termineter and OptiGuard work by combining knowledge of the C12.18 and C12.19 protocols with an ANSI type 2 optical probe, allowing the device to penetrate or test the optical diagnostic ports on smart meters supporting C12.18 interfaces.20 Once a meter is accessed, almost any parameter can be read, presenting a clear privacy issue (see Chapter 4, “Privacy”). In addition, many field service capabilities ranging from configuration changes to firmware updates can be initiated. This makes it possible to steal data from a meter, sabotage service to a meter, or install spyware or other malware.21
The limitations of C12.18 do present some challenges to a would-be hacker. For example, you have to be standing very close to a meter to establish a C12.18 optical connection. This limits the usefulness of these tools for any sort of large-scale cyber attack. However, individual meters are still widely accessible, and so its feasible an attacker could simply walk up to a meter—especially in rural areas—and hack the device.
Some of these limitations could also be overcome. For example, weaponizing tools using long-range infrared transmitters and receivers, an attacker could sit comfortably in a vehicle parked on the street. The attack itself could take several forms, anything from a brute force attack to obtain access, to a network capture and replay attack. Simply damage a meter and wait for the technician to show up. If the Smart Grid is working as designed, the failure will be identified and will trigger a ticket to dispatch a field service technician. Once the technician is onsite, capture the optical communications and later replay the tech’s authentication and replay attack the meter once the technician is offsite.
Attack methods
Once one or more Smart Grid assets have been discovered, and a target has been selected, there are many ways to execute a cyber attack. Depending upon the vulnerabilities of the target, these attacks could be very straightforward or may require a more sophisticated or indirect approach. Man-in-the-Middle attacks remain effective in many areas of the Smart Grid, as do network replay attacks. If a system can be penetrated and malware can be deposited (on disk or in memory), tools such as Metasploit’s Meterpreter can be used to provide remote access to Smart Grid consoles and controls, install keyloggers or keystroke injectors, manipulate control bits within industrial protocols, or almost anything.
In some cases, the information that is available can be used as reconnaissance for further cyber attack capability. In many cases, systems can be attacked directly using disclosed exploits, and knowledge of a system is all that’s required. If an attack is successful persistence can be established, enabling an attack to gather intelligence over time. In systems that make up a nexus between other systems (such as a substation gateway), a persistent presence can also be used to launch secondary attacks against other portions of the Smart Grid. This puts other systems at risk, such as data historians or other supplemental systems. Each successful attack can be used to gain access to more critical systems, up to and including bulk generation control systems.
In other cases, the information may be used to blend cyber and physical attacks. For example, determining when someone is at home by monitoring in-home energy signatures over time and then breaking into the home. In some cases, causing a localized failure in power delivery—by remotely disconnecting a smart meter, for example—could be used to bypass home security systems. Larger scale service disruption could be used to effect a power outage, allowing physical access to secure areas during the outage, or preventing quick response to a larger cyber incident by eliminating power from emergency response centers, SOCs, and other tactical monitoring stations.
Man-in-the-middle attacks
A Man-in-the-Middle (MITM) attack refers to an attack where the attacker inserts himself between communicating devices and snoops the traffic between them. The attacker is actually connecting to both devices, and then relaying traffic between them so that it appears that they are communicating directly, even though they’re really communicating through a third device, which is eavesdropping on the interaction. To perform a Man-in-the-Middle attack, the attacker must be able to intercept traffic between the two target systems and inject new traffic. If the connection lacks encryption and authentication—as is often the case with industrial protocol traffic—this is a very straightforward process. Where authentication or encryption is used, a Man-in-the-Middle attack can still succeed by listening for key exchanges and passing the attacker’s key in place of a legitimate key. It is relatively easy to intercept “secure” sessions (HTTPS, SSL, TLS). The biggest challenge to a successful Man-in-the-Middle attack is successfully inserting oneself into the message stream, which requires establishing trust. In other words, the attacker needs to convince both sides of the connection that it is the intended recipient. This impersonation can be thwarted with appropriate authentication controls. The attacker can present an invalid certificate to one device using SSL, connect to the target device, and establish a valid session. The first device is sending data encrypted, but the Man in the Middle is decrypting, inspecting, and then re-encrypting the traffic prior to delivering it to the second device. Unfortunately, many industrial protocols authenticate in clear text (if at all), or authenticated using weak (self-signed) certificates facilitating Man-in-the-Middle attacks within the various industrial controls systems throughout the Smart Grid.
Replay attacks
Initiating specific process commands into an industrial protocol stream requires an in-depth knowledge of industrial control system operations. However, because most industrial control traffic is transmitted in plain text, it is possible to capture packets and simply replay them to inject a desired process command into the system. For example, when capturing packets in a laboratory environment, a specific command can be initiated through a console, and the resulting network traffic can be captured, and when these packets are replayed, they will perform the same command. When commands are in clear text, it’s simple to find and replace a command from within captured traffic to create custom packets that are crafted to perform specific tasks. If traffic is captured from the field, authentications can be captured as well allowing an attacker to authenticate to a device via a replay attack, providing an authorized connection through which additional recorded traffic can be played back. In other words, the target device has been essentially rooted, and the attacker has absolute control. If the device is a PLC or other process automation controller such as the controller functions found in more advanced substation gateways, the behavior of an entire system could be altered. If the target is an IED, specific registers could be overwritten to inject false measurements or readings into a system.
Security researcher Dillon Beresford demonstrated a PLC replay attack at the 2011 Black Hat conference in Las Vegas, NV. The attack began by starting a Siemens Step 7 console and connecting to a PLC within a laboratory environment. Various commands were then initiated to the PLC via the Step 7 console while traffic was being captured. This traffic included a valid Step 7 to PLC session initiation, allowing the recorded traffic to be played back against any supported PLC to replay those same commands in the field.13
Replay attacks are useful because of the command and control nature of an industrial process control system. Because commands exist to enable or disable security, alarms, and logging features, a replay attack can easily render a target system helpless. Industrial protocols also enable the transmission of new code (for firmware or logic updates), allowing a replay attack to act as a “dropper” for malicious logic or malware. At the 2011 Applied Control Systems Cyber Security Conference, researcher Ralph Langner described how simple it can be to write malicious ladder logic: with just 16 bytes of code, a logic bomb can be inserted at the front of existing logic that will place the target PLC into an endless loop—preventing the remaining logic from executing and essentially “bricking” the PLC.22
For the subtle manipulation of automated Smart Grid services, knowledge of industrial control system operations is still required. However, much of the information needed to attack a PLC can be obtained from the device itself. For example, in Beresford’s case, packet replay was used to perform a PLC scan. Using S7 device requests via SIMATIC to probe a device, Beresford was able to obtain the model, network address, time of day, password, logic files, tag names, data block names, and other details from the targeted PLC.13
If the goal is simply to sabotage a system, however, almost anything can be used to disrupt operations: a simple replay attack to flip the coils in a relay switch is enough to break most processes.13 In fact, malware designed to flip specific bits can be installed on Smart Grid assets to manipulate or sabotage that asset: if only read values are manipulated, the device will report false values; if write commands are also manipulated, it would essentially render the protocol functionality useless for that device.
Popping the HMI
One of the easiest ways to obtain unauthorized command and control of a system is to leverage the capabilities of a human-machine interface (HMI) console. Whether an embedded HMI within a substation, or the centralized command and control capability of SCADA, EMS or other systems, the most effective way to manipulate those controls is via their console interface. Rather than attacking via the network using Man-in-the-Middle or replay attacks, a known device vulnerability is exploited to install remote access to the console. Specifically, by using Metasploit to exploit a target system, and then using Meterpreter to install a remote VNC server, the desktop of the target system is returned to the attacker’s PC. Now, the HMI, SCADA or EMS console is fully visible to and controllable by the attacker. This allows the hacker to directly monitor and control whatever that console is responsible for, remotely. There is no knowledge of industrial protocols needed, no specific experience in ladder logic, or control systems operations—only the ability to interpret a graphical user interface, click on buttons, and change values within a console that is typically designed for ease of use.
Blended attacks
Many attacks involve more than single exploits against a single vulnerability. Rather, more sophisticated attacks will use a blended threat model. According to SearchSecurity, “A blended threat is an exploit that combines elements of multiple types of malware and usually employs multiple attack vectors to increase the severity of damage and the speed of contagion.”23
In the past, blended attacks typically contained multiple types of malware that were used in succession: a spear phishing attack to attack systems behind a firewall that would then drop a remote access toolkit (RAT) and might also propagate through the corporate network using additional exploits.
Recently, blended threats have evolved to a much greater degree of complexity. This was first observed with St****t, a single complex and mutating malware framework that is capable of behaving in multiple ways depending upon its environment. St****t propagated using multiple zero day exploits, allowing it to spread quickly through enterprise networks, including exploits associated with removable media, allowing St****t to more easily spread to “air gapped” networks such as a SCADA or industrial control environments. All along the way, St****t analyzed its environment, looking for specific targets, and either adapted (to initiate the next stage of the attack) or deleted itself (to hide its tracks) depending on what it found. We therefore have a single malware framework that mutated and performed different enumeration and attack activities depending upon its environment—it was clearly the most sophisticated example of malware of its time. In addition to its complexity, St****t earned notoriety because it spanned all three zones of the “3 × 3” security model (see Chapter 5, “Security Models for SCADA, ICS, and Smart Grid”) to discover, penetrate, and sabotage a very specific industrial control: the enrichment of uranium.
Now, the concept of a blended attack residing within a self-contained, mutating payload has been taken even further. In June 2012, Kaspersky labs released information about Skywiper (more commonly known as Flame, one of the modular components of Skywiper). Skywiper is an even more sophisticated piece of malware, capable of “sniffing network traffic, taking screenshots, recording audio conversations, intercepting keystrokes, and managing other tricks that can compromise PC security and users’ private data.”24 Investigations revealed that, like St****t, Flame had been active for years prior to being discovered. The malware was actively mining sensitive data and returning it to a sophisticated command and control infrastructure consisting of over 80 domain names, and using servers that moved between multiple locations, including Hong Kong, Turkey, Germany, Poland, Malaysia, Latvia, the United Kingdom, and Switzerland.25
Evidence points to connections between St****t, Duqu, and Skywiper, which explains its sophistication as a natural evolution of this new breed of weaponized cyber attack. Skywiper is modular, and the breadth of modules within Skywiper allows it to be used for a broad range of purposes. According to McAfee’s security research laboratories, it is capable of, but not limited to, espionage functions such as scanning network resources, stealing information as specified, communicating with command and control (C&C) servers over SSH and HTTPS protocols, detecting the presence of more than 100 security products (antivirus, antispyware, firewalls, etc.), using both kernel and user-mode logic, employing complex internal functionality, injecting code and key processes, and concealing its presence. It can even create screen captures, record voice conversations, transmitting this back to the C&C infrastructure using multiple encryption methods.26
Over a dozen modules are present with Skywiper, including Flame, which handles AutoRun infection routines, “Weasel” and “Jimmy” which handle disk and file parsing, “Telemetry” and “Gator,” which handles command and control routines, “Suicide” for self-termination, and exploit modules such as “Frog” password stealer, “Viper” screenshot stealer, and “Munch” network packet capturer.26 Skywiper seems to be focused on espionage rather than sabotage: at the time of this writing, no modules dedicated to manipulation or sabotage of Smart Grid or other systems have been detected. However, the modular nature of Skywiper would certainly allows the threat to include more damaging modules as needed, no doubt leveraging the “Gadget” update module to further evolve the malware into a directed cyber weapon. When a creative attacker is able to combine modules of both St****t and Flame, he could in fact create advanced, customized malware targeting many Smart Grid architectures and systems.
Gauss, the newest sophisticated attack as of this writing, is also reminiscent of both St****t and Flame. However, rather than targeting industrial control systems or the industries that utilize them, Gauss focused on obtaining information from the banking industry. While not an example of a threat to Smart Grids per se, Gauss is indicative of a trend toward espionage versus data theft, using increasingly more sophisticated tools.
The trend toward targeted attacks using sophisticated, blended threats like these is of concern to the Smart Grid because the systems that make up the Smart Grid are so open and vulnerable. When many Smart Grid systems are visible on the Internet, it’s almost certain that the presence of a persistent threat will uncover vulnerabilities in these systems—or reconnoiter the information needed to uncover such vulnerabilities—and then further propagate among and between them. Of even greater concern is that many of these systems can be difficult to monitor, providing a relative safe haven for resident malware to hide dormant.
A common theme when discussing advanced attacks such as St****t, Flame, and Gauss is the mutability and adaptability of the malware. These attacks are designed to provide a command channel back to a remote site, but the beauty of the malware lies in their ability to conceal themselves, updates themselves, propagate to new systems and adapt to their environment. This allows the malware to establish persistence. Persistence can be used for prolonged espionage: stealing more and more information over time. It may also be used as a launching point for a secondary or tertiary attack phase. For example, after stealing data about a national grid infrastructure—including energy generation and utilization trends, outages and how they are handled, etc.—the malware could either activate a dormant module, or it may receive a new module or functionality through an update from the malware’s command and control framework. Consider the following functional example of a persistent, mutli-stage attack against a Smart Grid:
1. An advanced malware payload is distributed by redirecting the web request of a vendor technician through a malicious server, using the Kaminsky DNS exploit. The vendor’s technician downloads a firmware patch for a field device, but is actually receiving a counterfeit patch that contains malware.
2. The technician arrives on site, passes background checks, and his or her laptop passes a virus scan (because the malware is a zero-day virus that has no effective detection signature to date).
3. The patch drops a small payload into the project files of a substation automation controller, infecting field devices throughout the distribution system. This is done using an identified vulnerability in the industrial protocol used between them. At the same time, the malware attempts to propagate through the network from the technician laptop, establishing a persistent rootkit and opening a command and control channel back to a remote site. Since this is a targeted attack, the remote site would not be previously identified as malicious and reported as such by many threat intelligence systems.
4. The C&C channel may or may not be able to connect, depending upon the degree of network security and logical network separation that is place between the substation and other systems. In this example, there are open network connections to T-SCADA, D-SCADA and EMS systems that co-reside in a common data center.
5. At this stage, the gateway, field devices, RTUs, and other interconnected systems are infected. Depending upon which environment the virus resides in, new modules become active, and unused code is removed to conceal its presence. We now have a malicious framework operating in a coordinated manner within all zones of the grid system being attacked, from T&D automation, energy management, protection, metering, and even in-home systems such as HEMS and HAN-connected smart appliances.
6. Now the damage can be done: it can be pure reconnaissance, the theft of private information, or a coordinated attack designed to manipulate whole areas of the grid—all while hiding its actions from both human operators and management applications.
7. Once established, this persistent threat could further scan and enumerate other areas outside of the transmission system that it infected: breaching advanced metering systems to steal customer personal identity information (PII) and financial information, or to monitor home energy profiles to learn more about a specific target user, from what is in their refrigerator to what they’re watching on TV (see Chapter 4, “Privacy Concerns with the Smart Grid”).
Is this type of complex, staged attack realistic? Again, the answer has been proven by example. The S*****t virus combined clever code and forward thinking to provide detailed network enumeration that could easily act as a roadmap into and throughout target networks. With each new host infection, S*****t appended information to an encrypted data file as the malware propagated, which was then transferred home via the established C&C channel. This file provided an effective “road map” of how the malware reached its target, as well as how it propagated. This detailed network enumeration could be used to uncover other areas of attack and should the virus spread between multiple systems within a Smart Grid (as in the example provided above) could easily be used to map out sophisticated attacks against almost any system within the grid infrastructure, starting with whatever “weak link” the attacker is able to first identify and penetrate.
Setting phasors to kill
Unlike in Star Trek, the phasors referred to in transmission and distribution systems are simply measurements and are not harmful in and of themselves. However, because tripped lines in power transmission could cascade and cause outages similar to the 2003 blackout in Northeastern United States, synchronized phasor measurement has been a primary goal of newer, smarter grids.28 Could phasor measurement units (PMUs) be manipulated by a cyber attack to cause damages inline with the weapons of Gene Roddenbury’s fictional universe? Hardly, but because PMUs communicate digitally over a broad internetwork, they can be hacked, and this can lead to the exact type of cascading outage that they are intended to prevent.28
Using measurement systems as a target or vector for cyber attack is a bit less straightforward than installing malware, command and control callbacks, stealing data, etc. Because PMUs are very purpose-built devices, designed to obtain and communicate specific measurements, there is little damage that can be done outside of interrupting or manipulating these measurements. Unfortunately, the manipulation of phasor readings can cause damage to a transmission or distribution system, causing potential over-voltages or under-voltages on T&D lines or driving power out of phase. Specific lines could be targeted using EMS and DMS systems. Attacks could be highly specialized—such as jamming the GPS communications required to synchronize time across PMUs—or very general, such as installing malware within a PMU that alters phasor measurements as they are transmitted to a PDC. Phasor measurement manipulation could cause anything from loss of efficiency (putting T&D profitability at risk) to potential transmission line or generator trip, which could in turn lead to arcing or other serious risks to health and safety.
Researchers at the University of Texas and Northrup Grumman have shown how GPS spoofing can be used against phasor measurement units to manipulate the timing of a PMU. The hack works by spoofing a GPS and broadcasting a falsified GPS signal. Because PMU are based upon GPS time synchronization, spoofing therefore introduces a timing offset to the target PMU, and creates a corresponding change in the phase angle measured by the PMU.28
As with most highly distributed systems, PMUs rely upon a degree of centralization, and the Phasor Data Concentrator (PDC) is also a likely attack. There are no known instances of how a targeted attack against a PDC might be able to alter various distributed PMU data, although theoretically the same impact could be achieved in this way as by directly manipulating individual PDCs.
Attacking generation facilities from the grid
Discussions on Smart Grid attacks almost always originate from the Internet or from the utility’s business systems, spreading through to control facilities and ultimately into the grid. However, in the above example, the threat started in the field and worked its way into the control room from there. To the best knowledge of the authors, the first attack of this type occurred in an industrial manufacturing facility, where a corrupt plant device spread malware through the process and control networks to the company’s business systems. While details of this attack are not publically disclosed, this highlights the primary concern of Smart Grid cyber security that attacks can originate from almost any area, and propagate to almost any other. Often, the insider isn’t properly considered when designing their cyber security architecture: they are assumed to be trusted and all communications are allowed. This is a problem. If it is possible to inject code into a smart meter using infrared interfaces, through the advanced metering infrastructure to D-SCADA and T-SCADA severs via Windows vulnerabilities, and from there to business systems obtaining real-time information from the SCADA systems, there is no longer any security through separation nor security through obscurity. At the same time, per DoS attacks on distribution facilities to initiate truck rolls and deplete utility manpower resources. If secondary systems—such as coolant feeds and controllers—are accessible, shut down these systems to cause secondary faults in order to keep primary systems offline longer. Attacks originating in the field demand attention to securing the purpose-built and embedded devices and the communications between them, and also make a strong case for strengthening security of aggregation or concentration points in the field—such as AMI headends, substation gateways, and of course SCADA. They also reinforce the basic security premise within industrial networks of denying by default all communications, and only allow specific, known traffic between devices. This is difficult for many to understand, but in ICS design, it is all about managing trust and relationships—trust no one inherently! Some methods of implementing this type of hardening will be discussed in Chapter 6, “Securing the Smart Grid.” However, field-based attacks also present significant concerns and implications for supply chain management.
What about secure protocols?
The vulnerability of the Smart Grid to attacks originating through field devices has been seen in the wild. For example, in September 2012, Telvent, a major Smart Grid software vendor owned by Schneider Electric, was hacked. The breach of their corporate network resulted in the installation of malware as well as access to project files.32 While Telvent responded quickly with mitigation measures, this type of breach raises supply chain concerns. If a device manufacturer is breached and infected with sophisticated malware, there is a risk that attackers could have a persistent presence on the engineering workstations and systems of the vendors creating the field devices. This type of attack could both utilize the supply chain to gain access to target an ICS system at a client site, or to exfiltrate critical intelligence that could be used to compromise a client site through additional means.
According to Telvent, “OASyS DNA is a real-time SCADA [service] solution that bridges the gap between an enterprise network and activities in the field, delivering real-time data for critical business and operations decisions. It combines the systems your business already relies upon with technological solutions from our many software suites, our trusted partners and even our competitors. It seamlessly integrates every tool you need under a single umbrella of centralized, standardized hardware and software.”33
In other words, OASyS is like many SCADA systems in that it is a command and information nexus. Other leading ICS vendors like ABB, Emerson, Invensys and Honeywell to name a few offer similar services. The security implications of this or similar SCADA software being compromised within the supply chain is severe (this topic will be discussed in depth in Chapter 8, “Securing the Supply Chain”). The OASyS DNA system integrates information collected from Telvent SCADA, Schneider distribution management system, outage management, and other systems.33 This reinforces that almost any SCADA communication system is not only a tempting target on its own, but also an inbound vector to many other systems. If malware were to find its way into this or other similar SCADA systems from other manufacturers, it could be used as a sleeper agent to infiltrate almost any system throughout the Smart Grid.
A sophisticated attack and successful breach of a device manufacturer could provide remote command and control necessary for hackers to embed malware directly within the machines of program developers and engineers. At that point, project files, patches or other software delivered by the vendor to the end user could represent an inbound attack vector—a problem exacerbated by the fact that vendors typically have permissions necessary to modify systems within customer deployments.32 It should be noted that Telvent has taken measures to mitigate the risks associated with this breach. Always consult your vendor to obtain the latest information about vulnerability or breach disclosures, and validate vulnerability concerns via controlled penetration testing or suspect systems.
Summary
There are many systems that interconnect to make a “Smart Grid,” and all are susceptible to either a variety of general purpose attacks, and/or to specialized attacks that prey upon the distributed and easily accessible industrial protocols that are used within automation, measurement, metering and other specialized systems. While some devices are more secure than others (see Chapter 2, “Smart Grid Network Architecture”), the “weakest link” can be used as an attack vector into other devices due to the highly interconnected nature of the Smart Grid. Whether using common tools such as Metasploit, common techniques such as Man-in-the-Middle or network replay attacks, or specialized threats such as GPS spoofing against the synchrophasor infrastructure, the Smart Grid is vulnerable and accessible to a variety of attacks.
References
1. Peterson Dale, ed. S4 Proceedings series (digital bond’s SCADA security scientific symposium , 2007–2010). Miami, FL: Digital Bond Press; 2010.
2. William H, Bartley PE. Analysis of transformer failures In International association of engineering insurers 36th annual conference. Stockholm; 2003.
3. ICS-CERT. ICS-ALERT-12-046-01—increasing threat to industrial control systems. US Department of Homeland Security; February 15, 2012.
4. Knapp Eric D. Industrial network security: securing critical infrastructure networks for Smart Grid, SCADA, and other industrial control systems. Massachusetts: Syngress; August 29, 2011.
5. Franz Matt. DNP3 recon. Digital bond [document from Internet]; October 18, 2006. <http://www.digitalbond.com/index.php/2006/10/18/dnp3-recon/> [cited December 23, 2010].
6. Falliere Nicolas, Murchu Liam O, Chien Eric. Symantec. W32.St****t Dossier, Version1.4; February 2011.
7. Santamarta Ruben. Attacking controllogix. Digital Bond Project Base Camp.
8. Wurldtech Security Technologies. Achilles test platform product profile [Document on the Internet]. <http://www.wurldtech.com/cyber-security-products/achilles-testplatform/product-profile.aspx> [cited August 27, 2012].
9. ICS-CERT. ICS-CERT advisories and reports archive [document from the Internet]. <http://www.us-cert.gov/control_systems/ics-cert/archive.html> [cited October 20, 2012].
10. ODVA. [document on the Internet]. <http://www.odva.org/default.aspx?tabid=102> [cited August 27, 2012].
11. Digital Bond. Basecamp [document on the Internet]. <http://www.digitalbond.com/tools/basecamp/> [cited August 12, 2012].
12. Siemens AG. SIMATIC STEP 7 V11—controller software in the TIA portal [document on the Internet]. <http://www.industry.siemens.com/topics/global/en/tia-portal/controller-sw-tia-portal/pages/default.aspx> [cited September 5, 2012].
13. Beresford Dillon. Exploiting siemens simatic S7 PLCs. Prepared for Black Hat USA+2011. Las Vegas, NV; 2011.
14. Offensive Security. 7-technologies IGSS 9.00.00.11059 multiple vulnerabilities [document from the Internet]; March 22, 2011. <http://www.exploit-db.com/exploits/17024/> [cited September 1, 2012].
15. Langil Joel, Byres Eric. Analysis of the 7-technologies IGSS security vulnerabilities for industrial control system professionals. Tofino Security, SCADAhacker.com; March 28, 2011.
16. Langil Joel. Exploitation 101: turning a SCADA vulnerability into a successful attack [document on the Internet]. <http://www.scadahacker.com/videos/igss-video.html> [cited July 28, 2012].
17. Gleg, Ltd. SCADA+ Pack [document from the Internet]. <http://gleg.net/agora_scada.shtml> [cited September 4, 2012].
18. ANSI C12.18-2006, Protocol specification for ANSI type 2 optical port. American National Standard Institute, Inc.; May 2, 2006.
19. ANSI C12.19-2008. American national standard for utility industry end device data tables. American National Standard Institute, Inc.; February 24, 2009.
20. Fisher Dennis. Termineter security framework for smart meters released. ThreatPost [document from the Internet]; July 20, 2012. <http://threatpost.com/en_us/blogs/termineter-security-framework-smart-meters-released-072012> [cited September 1, 2012].
21. Menn Joseph. Web-connected industrial controls stoke security fears. Reuters. San Francisco [document from the Internet]; July 22, 2012. <http://in.reuters.com/article/2012/07/23/us-blackhat-industrialcontrols-idINBRE86M14R20120723> [cited September 1, 2012].
22. Lagner Ralph. Forensics on a complex cyber attack—lessons learned from St****t. In Presentation at the 2011 applied control solutions (ACS) conference, September 20, Washington, DC; 2011.
23. SearchSecurity. Definition: blended threat [document from the Internet]. <http://searchsecurity.techtarget.com/definition/blended-threat> [Cited September 4, 2012].
24. Mlot Stephanie. Kaspersky uncovers new details of Flame malware [document on the Internet]; September 18, 2012. <http://www.itproportal.com/2012/09/18/kaspersky-uncovers-new-details-of-flame-malware/#ixzz26pUY2u8P> [cited September 18, 2012].
25. Kaspersky Labs. Virus news: Kaspersky lab experts provide in-depth analysis of flame’s C&C infrastructure [document from the Internet]; June 4, 2012. <http://www.kaspersky.com/about/news/virus/2012/Kaspersky_Lab_Experts_Provide_In_Depth_Analysis_of_Flames_Infrastructure> [cited September 18, 2012].
26. Walter Jim. Flame attacks: briefing and indicators of compromise. McAfee Labs May, 2012.
27. US-CERT. ICS-CERT advisory ICSA-12-201-01—OSISOFT PI OPC DA interface buffer overflow; July 19, 2012.
28. Shepard Daniel P, Humphreys Todd E, Fansler Aaron A. Evaluation of the vulnerability of phasor measurement units to GPS spoofing attacks, In Sixth annual IFIP WG 11.10 international conference on critical infrastructure protection. Washington, DC; March19–21, 2012.
29. Technical IEC Specification TS 62351-1. Power systems management and associated information exchange—data and communications security Part 1: Communication network and system security—Introduction to security issues. International Electrotechnical Commission (IEC): Geneva, Switzerland; 2007.
30. Goodin Dan. Many ways to break SSL with CRIME attacks, experts warn. ArsTechnica [document from the Internet]; September 17, 2012. <http://arstechnica.com/security/2012/09/many-ways-to-break-ssl-with-crime-attacks-experts-warn/> [cited October 1, 2012].
31. CVE-2009-355. Mitre. 2009 [document from the Internet]. <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555> [cited October 1, 2012].
32. Zetter Kim. Maker of Smart-Grid control software hacked. Wired [document on the Internet]; September 26, 2012. <http://www.wired.com/threatlevel/2012/09/scada-vendor-telvent-hacked/> [cited September 27, 2012].
33. OASyS SCADA: Standardized, centralized SCADA solutions from Telvent [document on the Internet]; 2012. <http://www.telvent.com/en/business_areas/smart_grid/solutions_overview/smart_grid/smart_operations/oasys-scada.cfm> [cited September 27, 2012].