Abstract
The purpose of this exercise is essentially two-fold in areas of research: active reconnaissance methods and automated process control protocols. First, the concept of ‘active reconnaissance’ is examined along with the tools used in these types of attacks. A functional installation of a subset of these tools is implemented for use within a mock-up penetration testing environment. In addition, network and security model classification of these tools are presented, along with methods for concealment in their use. Furthermore, existing literature presented on these topics is evaluated. In relation to the second area of research, a number of Supervisory and Data Acquisition (SCADA) protocols are listed and their relationship to common network models is explored. Finally, the possibilities associated with the malicious use of these SCADA protocols are examined.
Introduction
In the execution of the first part of this exercise, it became increasingly apparent that the definition of ‘active reconnaissance’ would set the direction our research would take. It also became obvious that classification of an attack tool was much clearer within the scope of a specific scenario: the intent with which a tool was used was more discernable within the context of an entire attack taken as a whole, rather than individual events. It is with these factors in mind that we define ‘active reconnaissance’ as having these necessary components: presence, risk, and limitation of scope.
Presence, within this definition, refers to the idea that the attacker must be identifiable as an agent within the bounds of the target’s controlled resources, whether this is a physical presence, or an electronic presence via software or packets in transmission. The factor of risk is closely associated with presence: simply put, the attacker must be put in a position where the threat of detection is real. To clarify the need for this definition, take for example a typical name server query: the hypothetical attacker is present and engaging the target’s resources directly, but there is no element of risk as it is information ‘intended’ to be freely given in the normal course of operation (we would classify this as ‘passive reconnaissance’) .
Finally, the ‘limitation of scope’ is much harder concept to state concisely: we present that ‘active reconnaissance’ must be ‘a means to an end’ and not the ultimate objective of an attack. It must be admitted that this ‘limited scope’ may only exist transitionally, as the speed of electronic attack may put the definable ‘phases of attack’ into the frame of milliseconds. Ultimately then, we must loosely define this ‘limited scope’ as: attacks which are ‘preparatory’ in nature, any damage being a side effect of the primary process of collecting information about the target’s structure and defense mechanisms.
It is with this definition in mind that we address the first area of research: What is an ‘active reconnaissance’ attack tool? Additionally, we ask: what tools of this nature are readily available, and what areas of networking and security models do they attack? Furthermore, we explore means by which a user of these tools can be concealed from a target. We then research a variety of Supervisory and Data Acquisition (SCADA) protocols available, and fit them into the scope of existing network models and exploit tools.
Literature Review
The bulk of this week’s readings pertain to penetration testing procedures and techniques. The readings also cover some definitions used in Red Teaming and describe the difference between black, white and gray ethical hacking. Automated Red Teaming as it applies to military applications is also covered. This section describes the readings in more detail. It also ends with a review of the readings and explains how they pertain to our lab.
In “About Penetration Testing” (Bishop, 2007) the author states that it’s not enough to set the goal as “break into the system” (p. 84). It is necessary to define goal of penetration testing, such as read a file or impersonate a user. He also states that those performing the penetration test should know everything about the system prior to performing the testing. This helps to make up for the lack of time and resources that are usually available to the attackers. He further warns against “security through obscurity” (p. 85), which means relying on an attacker’s lack of knowledge of the system to keep the system safe.
In “Three Different Shades of Ethical Hacking: Black, White and Gray” (Hafele, 2004) the author details the need for penetration testing and then describes the difference between the three approaches to ethical hacking, black, white and gray. He describes penetration testers as “ethical hackers” (p. 2), and further states that a good penetration tester should be able to recommend solutions to solve the security problems that were identified (p. 4). In the Black Box model, very few members of the organization being tested are aware that the test is taking place. In this model, the penetration testers have very little initial knowledge of the system and are therefore forced to gather the information from whatever sources are available prior to performing the test (p. 6). The Black Box Model most closely emulates the steps that a real hacker would have to perform to penetrate the system. In the White Box method, many members of the organization know about the testing project. The penetration testers gather large amounts information about the system from within the organization prior to conducting the penetration test (p. 12). The Gray Box approach is a hybrid between the two. In this method, penetration testers are fed only certain information, while they are forced to gather other information on their own (p. 17).
In “Security Plan for Red Team Testing” (Bishop, 2007) the author discusses the security methods used when conducting penetration testing on a voting system. The system is divided into two separate systems, red and green (p. 2). Any data transferred between the two machines is done so only by removable media. The green system is attached to internet while the red system is stand-alone. The red system contains the sensitive data. Personal electronic devices are considered green devices (p. 3).
In “Automated Red Teaming: A Proposed Framework for Military Applications” (Choo, 2007) the author discusses using computer applications using the evolutionary algorithm for simulated red teaming. Although the article discusses automated red teaming for military combat situations, the concept can be extended to red team penetration testing of computer systems.
In “Grammar Based Whitebox Fuzzing” (Godefroid, 2008), Whitebox fuzzing is described as “automatic dynamic test generation, based on symbolic execution and constraint solving, designed for security testing large applications”(p. 206). Whitebox fuzzing uses an initial well formed input for the dynamic test generation (p. 206). Blackbox fuzzing on the other hand is described as randomly modifying inputs and testing the results to find security vulnerabilities (p. 206). This article proposes an enhancement to whitebox fuzzing in cases that require highly structured inputs, such as interpreters and compilers (p. 206). Because interpreters and compilers process inputs in stages, malformed input often doesn’t make it to the deeper stages of the processing. Grammar based whitebox fuzzing uses grammar based specifications of valid inputs to avoid rejection of unparsable inputs in the early stages of processing (p. 213). Grammar-based whitebox achieves the best total coverage in the deepest module, the code generator (p. 213).
According to “Matching Attack patterns to security vulnerabilities in software intensive designs” (Gegick, 2005) many intrusions are based on a small number of known attacks (p. 1). These attack patterns can be identified, stored in a library and used to identify vulnerabilities early in the software development process (p. 5). Because the attack patterns are abstract, they can be used regardless of programming language. Attack patterns that are specific to a particular product are ignored. The graphical models used are attack trees and attack nets (p. 2). The author defines attack trees as “tree diagrams (that can also be converted to text) whose nodes show the goals of an attacker” (p. 2). Attack trees show the point of view of an attacker completing steps toward his or her final objective. Attack nets “show specific components of a system [and are used] to identify precisely where in the system penetration testing should occur” (p. 2).
In “Attack Net Penetration Testing” (McDermott, 2001) the author advocates using process models to make penetration testing more efficient (p. 15). Two approaches to penetration testing are described, flaw hypothesis and attack tree. Flaw hypothesis model describes 6 steps that are used in penetration testing; Define goals, Perform background study, Generate hypothetical flaws, Confirm hypothesis, Generalize discovered flaws, and Eliminate discovered flaws (p. 15). The attack tree uses a work breakdown structure chart borrowed from project management. The target of the attack is root of the tree, with the nodes being the possible steps that can be taken to reach the root (p16). This paper introduces a new approach to process modeling, the use of a Petri net (p. 16). With this approach, places represent the state of the system and transitions represent events that act on the system to change the state. A token represents the current progress of an attacker (p. 17). When a token is located at a place, the attacker has gained control of that place. Tokens move from place to place via directed arcs by transitions toward the target (p. 17).
“Fast Model Based Penetration Testing” (Singh, 2004) proposes performing repeated penetration testing using detailed system models to obtain statistically valid estimates of security metrics (p. 309). This approach is called “Model-Based Penetration Testing” (p. 309). In this approach, a complex model of the system is built that allows for automatically generated repeated attacks (p. 309). The model uses hosts, trust relationships, services, and states. It advocates determining probabilities based on these metrics. Of particular interest are the number of paths and total number of steps to achieve a goal. They are used to indicate difficulty of achieving that goal (p. 311).
As we move forward with penetration testing labs in this course, process modeling will assist us in planning and organizing our attacks. Process modeling was discussed in “Fast Model Based Penetration Testing” (Singh, 2004, p309), “Matching Attack patterns to security vulnerabilities in software intensive designs” (Gegick, 2005), and “Attack Net Penetration Testing” (McDermott, 2001). Penetration testers that use process models are more efficient (McDermott, 2001, p15). “Grammar Based Whitebox Fuzzing” (Godefroid, 2008) discusses various fuzzing techniques that can be used in the penetration testing labs. This knowledge of fuzzing techniques will be useful when we perform penetration testing in our labs by showing us how generated input can be used to test software. “Three Different Shades of Ethical Hacking: Black, White and Gray” (Hafele, 2004) discussed categorizing ethical hacking based on the amount of knowledge that the penetration testers have of the system. The type of penetration testing we are using in this course would fit into the white box model due to our detailed knowledge of the target system. The article “About Penetration Testing” (Bishop, 2007) advocates the whitebox approach.
Of further interest with regard to theoretical attack models, “Automated Red Teaming: A Proposed Framework for Military Applications” (Choo, 2007) outlined a computerized system that simulates military combat. Although not directly related to computer penetration testing, it does further define Red Teaming. It also describes an automated system used to simulate military Red Teaming that may be extended to test distributed computer systems. “Security Plan for Red Team Testing” (Bishop, 2007) discussed the need for creating a completely stand alone system for conducting penetration testing when the system being tested involves sensitive information. Our labs are not going to involve sensitive information; therefore we are creating independent systems (although not isolated) by using VMware to create a virtual distributed system. With regard to the technical accuracy of the literature, no obvious errors or discrepancies were apparent.
Methodology
It was decided that the list of general exploit tools created in the previous week’s research would become the basis for further research in this exercise. We believe this truncated list to represent a significant sampling of the available ‘active reconnaissance’ tools available to persons involved in the data security field. It was also decided that existing security tool based distributions (in the form of image files) would become the basis for the ‘installable’ tools within our virtual testing environment via virtual machine creation. This was done for two reasons: these distributions represent a significant collection of tools in numerical count, and they also have been subject to a type of peer review intrinsic to creating a distribution ‘for the professional community.’
Additionally, to maximize the use of available resources, it was determined that those with prior experience in SCADA protocols would take the lead in exploring this area, and would submit a report to the rest of the team. This allowed the team to efficiently partition responsibilities, with the final research being disseminated to the team members for review and evaluation: the end result being a collaborative effort over the entire scope of the work.
Procedure
The previous week’s list of general exploit tools was evaluated, with tools obviously unsuited for active reconnaissance being eliminated in a first pass. Research was conducted via web search and documentation included with tool distributions to determine the capabilities of the remaining tools. Many more tools judged unsuitable were eliminated in this second pass. At this point, a concrete definition based on ‘presence, risk, limitation of scope’ had emerged by which to judge the remainder of the list. A third pass was made, with the aforementioned criteria used to remove any tools which did not fit this profile.
Various professional security tool distributions were downloaded from the internet. These included ‘Knoppix-STD’ and ‘nUbuntu,’ with the ‘Backtrack 4 Beta’ distribution already being available locally. The ‘Backtrack’ and ‘Knoppix-STD’ image files were burned to disc, and run on a live network with real hardware. Additionally, all of these distributions were run in VMware Player as guest operating systems on a Windows Vista host in bridged network mode, these VMs being evaluated for use within the Citrix shared test environment. A number of tools were tested on a live network, which included: FreeBSD, Windows XP SP3, Windows Vista, and embedded Linux hosts. Additionally, a Linksys SIP box, a Cisco-Linksys router/ wireless AP, and a Hewlett Packard print server were present for the tests.
Research was conducted on techniques for creating anonymous connections, with the sources related to the relatively well known ‘Tor’ network used as a starting point. This led to an extensive collection of work located at the ‘freehaven.net’ website, of which a number of the published papers proved informative. Predominately, uses of proxies and ‘onion routing’ techniques were examined. This proved to be a useful addition to the information previously acquired through security tool documentation.
Various sources considered to be authoritative were consulted with regard to the SCADA protocols. Additionally, the issues related to SCADA, OSI, and TCP/IP were examined with regard to informed sources of information. A synthesis of protocol definitions was created, and a diagram which reflected the classification of theses protocols with respect to the OSI model and TCP/IP was fashioned.
Results and Discussion
Summary of Results
A summary of the active reconnaissance and SCADA research are presented in tables one and two, respectively.
Active Reconnaissance Tools
The classification of the ‘active reconnaissance’ tools was relatively straight forward. It was found that creating a logical definition with relation to tool function was a great aid in classification. The construction of the testing environment for tool evaluation was fairly mundane, with only one relatively minor problem encountered in setup. The various network mapping tools appeared to work as indicated in the documentation, usually presenting a list of live IP addresses and/or active ports to the console. A number of the SIP based tools were employed against the Linksys SIP box, but the results were unremarkable. The researcher must confess that this may be due to unfamiliarity with the tools used and VOIP protocols in general: further investigation is in order as time allows. A number of the SNMP scanners were tested, and the Hewlett Packard print server was found to have an active interface available in the ‘public’ community. It was discovered that the quantities of printer consumables could be read via the SNMP scanners: a somewhat interesting result. No other devices with SNMP services were detected on the network, although unfamiliarity with the tools may have been a factor in this. In sum, we verified that these tools appear to function in the advertised manner, and so can be relied on in situations where verification of results by direct observation cannot be obtained.
Anonymizing the Attacker
Our research has led us to conclude that three general means can be used to ‘hide’ an attacker from the target. These can be grouped into: proxies, obfuscation, and ‘out-of-band’ communications. Generically, proxies are entities through which an attacker can route packet transmissions, and by doing so disguise the actual origin from which the packets came. A modern implementation of a network for anonymous communication is the Tor network, which relies on the principles of ‘onion routing’ by which to create nearly untraceable connections. Onion routing is effective in hiding connection details, as each node only ‘knows’ one link of the communication chain, with the remainder of the connection details and payload being hidden under multiple layers of encryption ( like an onion) (Goldschlag, Reed, and Syverson, 1996, p. 4).
An equally effective approach for a determined attacker is to create a ‘private’ proxy network using compromised internet connected hosts. The attacker may delete log files and records on these compromised machines at will, assuring nearly total anonymity (at the price of legality). Furthermore, it is difficult for an attacker’s victim to gain access to these compromised machines, as they often cross geo-political borders. While proxies are effective in hiding the origin of connections, the traffic generated is easily spotted on a network (usually encryption tunnels), and are relatively easily defeated using simple means, such as alteration of gateway firewall rules.
Obfuscation in the context of this discussion is used to describe any means by which a hidden communication channel is created utilizing the TCP/IP protocol suite. Murdoch and Lewis (2005) described various means by which steganography, or the covert encoding of information within other information, can be performed on TCP/ IP packets (pp. 3 -7). Additionally, such security tools as ‘fragrouter’ are intended to defeat intrusion detection systems (IDS) by exploiting the inability of some systems to handle fragmented packets. In theory, these methods could be used to establish a covert data channel for passing information in and out of a target’s network in spite of security precautions. It should be mentioned that an attacker could use these obfuscation methods in conjunction with external proxies-creating multiple layers of separation from the target.
Finally, ‘out-of-band’ communications, when available, offer the attacker a means by which to bypass any security precautions in effect on the primary TCP/IP network. Gula (2001) spoke of the risk of out-of-band exploits originating from ISDN based data connections (p. 13) We propose, that rather than being the primary point of attack initiation, these type of external connections could be used to create an unmonitored data channel extending outward from the target’s network ‘after’ a successful penetration has been attained via some other means. These channels could literally be any route which offers a communications path leaving the target’s facility, whether analog or digital. A simple example would be a network attached modem based fax server: a security tool such as ‘lanmap’ can create a .png based network map, which can then be sent to some external number via the fax server. In reality, this transmission would likely never be detected by the target; thereby effectively hiding the attack (and thus the attacker).
TCP/IP
We chose the traditional four layer model for TCP/IP. The original RFC published by the Internet for communication layer requirements for Internet hosts designates the four layer model (Braden 1999 p. 9, 10). The document also states that “The system must tolerate a wide variety of networks”(Braden 1999, p.8). This means that while a physical medium must be in place for communication, there are no specific requirements as long as interoperability is assured.
It is true that some experts add a fifth, physical or hardware layer to model, William Stallings and Douglas Commer are prominent examples. Neither gives any explanation for why they added the additional layer, though again obviously it must exist (Commer 2005, p 116; Stallings 2006, p. 35). In reality, it’s a moot point the model is just that, a model. It is designed to visualize the communication process between two networked devices. Whether the physical portion is displayed or assumes depends on the needs and tastes of the user.
SCADA: Modbus
Modbus was originally designed in 1979 to provide serial communication to process automation devices. The current implementation of the Modbus protocol stack actually has two wings. One is for communication with on a TCP/IP network, the other is for device communication (Modbus-IDA; 2006, p. 2). The application communicates with a TCP interface layer and then the TCP/IP stack. The other wing uses a transmission control protocol to communicate over asynchronous serial links to process automation devices (Modbus-IDA; 2006, p. 2). The kinetic output noted in the chart is delivered through a motion controller or drive, though Modbus can be used with several different types of devices (Modbus-IDA; 2006 p. 2).
SCADA: DNP3
Distributed Network Protocol version 3.0 (DNP3) is designed to be used in sensor networks to monitor remote electric substations. It has found its way into widespread use across other utilities and industries as well. This protocol was developed simultaneously with the IEC 60870-5-101 standard (Triangle Microworks 2006, p.3). The protocol uses the stack shown to communicate to the sensors and interfaces with TCP/IP networks using an application layer using an Internet transport interface (Cole 2003, p. 2).
SCADA: DeviceNet
DeviceNet is part of the Common Industrial Protocol (CIP) suite designed by the Open DeviceNet Vendor Association (ODVA) (Voss 2008, p. 4). It uses a controller area network (CAN) at the data link layer (ODVA 2008, p. 5). DeviceNet interfaces with TCP/IP networks at the application layer via the broader CIP suite (ODVA 2008, p. 8).
SCADA: Other protocols
There are several other proprietary and open process automation protocols. The group researched Allen-Bradley’s DH+ protocol and the open PROFIBUS protocol designed by Siemens. Our research finds that the majority of the protocols all fit one of these models, having application, Data link, and physical layers and conforming to IEC 61158 (Zurawski 2005 p. 7-17).
SCADA: Exploitability
As Goodin (2008) noted, though SCADA systems are often assumed to be safe from exploit as they are not directly connected to the internet, this does not prevent attackers from attacking through unsecured local wireless networks or compromising control software accessible from the internet (par. 6). Additionally, at least one SCADA attack is known to the general public, and is available through the Metasploit framework, specifically in Kevin Finisterre’s CitecSCADA exploit (par. 3). This exploit utilizes TCP/IP packet size manipulation to cause a buffer overflow on the CitecSCADA server through Open Database Connectivity (ODBC) flaws (par. 7).
The availability of publicly known SCADA exploits is a serious warning flag with regard to future SCADA attacks. While these attacks may require more sophistication and effort to execute than a typical network intrusion, this will not stop a determined saboteur. This is particularly true when a saboteur is a disgruntled employee (possibly: former employee) or has access to these individuals. Additionally, the use of control software with standard TCP/IP protocols and services greatly increases the exposed ‘threat area’ available for indirect SCADA attacks.
Problems and Issues
Two significant problems emerged in the duration of this research. The first was the ambiguities associated with classifying an exploit tool as an ‘active reconnaissance’ type. It was realized that in many cases, the attacker will likely have already engaged in employing a direct exploit on a host in order to obtain access to the local network. We began to realize that attack patterns can develop in many ways, and that ‘exploits’ and ‘passive’ methods are often the stepping stone by which ‘active’ reconnaissance can be achieved (through a compromised host). The development of the ‘presence, risk, limitation of scope’ definition helped in dispelling some of these ambiguities, but it bears all of the characteristics of a ‘nice’ theoretical model-in ‘real world’ application it may prove to be of little worth.
Secondly, stability problems were encountered with the ‘BackTrack 4 Beta’ release used for the tool-utilization test machines. These stability problems were the primary reason that alternative distributions were obtained and employed within the scope of this research. In retrospect, it was a mistake to rely on a ‘beta’ distribution for any serious application. In some respects, this became a positive factor, as it forced us to expand the breadth of our research to other avenues of inquiry. Overall, this problem was easily addressed by substitution with an equivalent stable release and presented no permanent roadblock in the execution of this exercise.
Conclusions
Our research has covered active reconnaissance tools and automated process control modules. We prepared a review of selected readings, and applied these to the exercise. We crafted a clear definition of ‘active reconnaissance,’ specifically relating to the characteristics of: presence, risk, and limitation of scope. This definition was used to select relevant security tools. The tools were then classified by their placement within the OSI model, and respective McCumber cube coordinates assigned. We presented various means by which an attacker could evade identification; namely, by using: proxies, obfuscation, and out-of-band communications. In addition to this, active reconnaissance tools were tested against a live network and the results documented. A number of Supervisory and Data Acquisition (SCADA) protocols were examined, and also classified by placement within the OSI model; additionally, the layers of the TCP/IP protocol suite were identified and classified by their placement on the OSI model. Finally, we discussed known SCADA vulnerabilities, and the reality of future attacks.
Charts, Tables, and Illustrations
Table 1 Active Reconnaissance Tools
|
Layer 1 |
Non-destructive disassembly (active, physical: risks detection) |
Technology, Processing, Confidentiality |
|
Layer 1 |
Hardware substitution (active, physical: risks detection ) |
Technology, Processing, Integrity |
|
Layer 1 |
Electromagnetic imaging (active emissions: risks detection ) |
Technology, Processing, Confidentiality |
|
Layer 1 |
Theft (active, physical: high risk of detection) |
Policy-practice, Confidentiality, Storage |
|
Layer 1 |
NetStumbler (active scanning) |
Technology, Transmission, Confidentiality |
|
Layer 2 |
ifconfig (MAC id, host impersonation: detectable) |
Technology, Transmission, Integrity |
|
Layer 2 |
GNU MAC Changer (detectable) |
Technology, Transmission, Integrity |
|
Layer 2 |
Ettercap (active scanning capability through common plug-ins) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
Angst (active packet scanner) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
Sing (categorically similar to ‘ping’) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
Ass (active router query) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
igrp (route injection, packet redirection) |
Technology, Transmission, Integrity |
|
Layer 3 |
Packit (active packet forging/injection) |
Technology, Transmission, Integrity |
|
Layer 3 |
ping (host discovery) |
Technology, Transmission, Availability |
|
Layer 3 |
Fragrouter (various active, including detection evasion) |
Technology, Transmission, Availability |
|
Layer 3/4 |
Superscan (active network scanner) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
Nmap (active network scanner) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
Hping2 ( see ‘ping’) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
DMItry (capable of port scans) |
Technology, Transmission, Confidentiality |
|
Layer 3 |
TCtrace (categorically similar to traceroute, active: detectable) |
Technology, Transmission, Confidentiality |
|
Layer 3/4/5/7 |
PBNJ (uses Nmap) |
Technology, Transmission, Confidentiality |
|
Layer 3/4/5/7 |
Unicornscan (multi-tool, capable of active scans) |
Technology, Transmission, Confidentiality |
|
Layer 3/4 |
Strobe (port scanner) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Nessus (active scanner) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Netcat (scriptable, multi-purpose active interrogation) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Firewalk (active firewall auditor) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Socat (improved netcat, with SSL) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
SinFP (Frame finger printer, has active connection based fingerprinting capabilities) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
sbd (improved netcat) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Telnet (generic active connection tool) |
Technology, Storage, Confidentiality |
|
Layer 4 |
C/C++ BSD socket API (unlimited active recon potential) |
Technology, Storage, Confidentiality |
|
Layer 4 |
Pearl script with sockets (unlimited active recon potential) |
Technology, Storage, Confidentiality |
|
Layer 4 |
Python script with sockets (unlimited active recon potential) |
Technology, Storage, Confidentiality |
|
Layer 4 |
Amap (host service detection scanner) |
Technology, Transmission, Confidentiality |
|
Layer 4 |
Packit (custom packet creation, active firewall and IDS evaluation) |
Technology, Transmission, Confidentiality |
|
Layer 4/5/6/7 |
MBSA (Microsoft Baseline Security Analyzer, active client scanning: detectable) |
Technology, Storage, Integrity |
|
Layer 5 |
hackbot (scanner, banner grabber) |
Technology, Storage, Integrity |
|
Layer 5 |
SMTP verify (active interrogation of mail server: detectable, especially when automated) |
Technology, Storage, Confidentiality |
|
Layer 5 |
Nbtscan (active NETBIOS server scan: detectable) |
Technology, Storage, Confidentiality |
|
Layer 5 |
NAT (NetBIOS Auditing Tool, active connection: detectable repeated query pattern) |
Technology, Storage, Confidentiality |
|
Layer 5 |
NMAP |
Technology, Storage/Transmission, Confidentiality |
|
Layer 6 |
Ike-scan (active VPN scanning) |
Technology, Transmission, Confidentiality |
|
Layer 6 |
SSLScan (active connection required, detectable) |
Technology, Transmission, Confidentiality |
|
Layer 6 |
ScanSSH (active scanner) |
Technology, Transmission, Confidentiality |
|
Layer 6 |
PuTTY (general purpose active connection tool) |
Technology, Storage, Confidentiality |
|
Layer 7 |
Nikto (uses libWhisker, HTTP active scanning: can be used for information gathering) |
Technology, Storage, Integrity |
|
Layer 7 |
uberkey (keylogger, active snooping: risk of detection) |
Technology, Storage, Confidentiality |
|
Layer 7 |
VNCcrack |
Technology, Transmission, Confidentiality |
|
Layer 7 |
Braa (SNMP active scanner) |
Technology, Processing, Integrity |
|
Layer 7 |
Amap (active host service detection) |
Technology, Storage, Confidentiality |
|
Layer 7 |
xspy (Xserver polling, active, detectable) |
Technology, Transmission, Confidentiality |
|
Layer 7 |
Whisker (active HTTP scanning) |
Technology, Processing, Integrity |
|
Layer 7 |
SARA (suite of tools, many active in nature) |
Technology, Processing, Integrity |
|
Layer 7 |
Inguma (suite of tools, many active) |
Technology, Storage, Confidentiality |
|
Layer 7 |
Relay Scanner (active SMTP interrogation) |
Technology, Storage, Confidentiality |
|
Layer 8 |
Theatrics ( physical, onsite creation of scenarios to test security capabilities) |
Policy-practice, Confidentiality, Storage |
|
Layer 8 |
Impersonation (facilitates onsite reconnaissance) |
Policy-practice, Confidentiality, Storage |
|
Layer 8 |
Camaraderie (facilitates indirect reconnaissance; active in the sense of direct interaction with personnel: substantial risk of betraying pending attack ) |
Policy-practice, Confidentiality, Storage |
|
Layer 8 |
Surveillance (physical presence near target: risk of discovery) |
Policy-practice, Confidentiality, Processing |
Table 2 TCP/IP and SCADA Protocol Stacks
References
Bishop, M. (2007). Security Plan for Red Team Testing. pp. 1-3.
Bishop, M., & Frincke, D. A. (2007). About Penetration Testing. pp. 84-87.
Braden, R. (1999). Requirements for Internet Hosts – Communication Layers. RFC 1122, Internet Engineering Task Force Network Working Group: 116.
Choo, C. S., Chua, C. L., & Tay, S.-H. V. (n.d.). Automated Red Teaming: A Proposed Framework for Military Application. pp. 1936-1942.
Cole, G. B. (2003). Report 053-6: An Introduction to IEC 60870-5-104, A Standard for the Telecontrol of Electric Power Transmission Systems, Using Internet Communication Services, International Electrotechnichal Commission 5.
Commer, D. E. (2005). Internetworking with TCP/IP: Principles, Protocols and Architecture. Chicago, Prentice Hall.
Gegick, M. (2005, May 16). Matching Attack Patterns to Security Vulnerabilites in Software-Intensive System Designs. pp. 1-7.
Godefroid, P., Kiezun, A., & Levin, M. Y. (2008, June 13). Grammar-Based Whitebox Fuzzing. pp. 206-215.
Goldschlag, D. M., Reed, M. G., and Syverson, P. F. (1996). Hiding Routing Information. In R. J. Anderson (Ed.), Proceedings of the First international Workshop on information Hiding : Vol. 1174. Lecture Notes In Computer Science (pp. 137-150). London: Springer-Verlag.
Goodin, D. (2008, September 8). Gas refineries at Defcon 1 as SCADA exploit goes wild. The Register. Retrieved June 20, 2009, from http://www.theregister.co.uk/2008/09/08/scada_exploit_released/
Gula, R. (2001). Broadening the Scope of Penetration-Testing Techniques. Enterasys Networks White Paper , pp. 1- 18.
Hafele, D. M. (2004, February 23). Three Different Shades of Ethical Hacking: Black, White and Gray. pp. 1-22.
McDermott, J. P. (2001). Attack Net Penetration Testing. pp. 15-21.
Modbus-IDA; (2006). MODBUS Application Protocol Specification V1.1b, Modbus IDA: 51.
Murdoch, S. J. and Lewis, S.( 2005). Embedding covert channels into TCP/IP. In M. Barni, J. Herrera-
Joancomarti , S. Katzenbeisser and F. P´erez-Gonz´alez (Ed.), Proceedings of the Workshop on Information Hiding (IH 2005), 247-261.
ODVA (2008). DeviceNet – CIP on CAN technology. Ann Arbor, ODVA: 8.
Stallings, W. (2006). Data and Computer Communications. Chicago, Prentice Hall.
Singh, S., Lyons, J., & Nicol, D. (2004). Fast Model-Based Penetration Testing. pp. 309-317.
Triangle Microworks (2006). DNP3 Overview. Raleigh, Triangle Microworks Inc. : 5.
Voss, K. (2008). The CIP Advantage: Proven and Future-Proof, CIP Provides A Unified Architecture For Delivering Standards-Based Open Networking Technologies Throughout the Enterprise. Ann Arbor, ODVA: 10.
Zurawski, R. (2005). The Industrial Communication Technology Handbook. Boca Raton CRC Press.
Team three begun their lab with an abstract that while doing a good job of explaining what was going to be accomplished in the lab, did not meet the requirements of the syllabus in terms of length. Team there had a very complete introduction to the definitions as they found would apply both to the literature review and the tasks of the lab itself. The introduction, while like team one, in that there was one, team three had a much more defined introduction that put the reader in the mindset of the lab. This introduction read as though from someone who has had experience with active recon in the past, maybe not network based, but active recon nonetheless. After the introduction the literature review, while covering all of the assigned literature, did read as a list of analyzed literature with APA style citations. They did manage to bring the disparate articles to a cohesive finish, but I question if that method makes for a scholarly and effective literature review. Team three broke their methods into two sections, one for pure methods, and one for procedural methods. The combination of the two results in a complete and accurate methods section. There is no improvement need be made to the methods for this lab, as they offer scholarly and accurate information. Team three has a very complete section on anonymizing the attacker, but I fail to see a reference to professor Liles blog anywhere in the lab. Team three appears to agree with team one in that they chose to use the four layer TCP/IP model, but explain where some believe there is a fifth. Where I question their TCP/IP model information is in how they do not provide a reason for Stallings claiming a fifth layer. Team one presented a reason from Stallings, however team three listed that no reason was available. Team three then goes into how the chosen SCADA protocols fit in with the OSI model, and give a brief description of each protocol, followed by a section on exploiting SCADA. Thus approach seems to be rather effective in explaining SCADA attack vectors, rather than listing vectors for each. Again team three said nothing about MODBUS TCP port 502, which seems to be an omission as in my mind is a rather important part of MODBUS. Team three presented well-found conclusions and their technical position cannot be questioned in my opinion. The table of active recon tools is seemingly well formatted, and balanced, but upon further review they placed tools in multiple layers of the OSI model instead of the best fit layer making the table more difficult to read. Team three also lacked in their SCADA table. I found it be simpler to read than team ones, the color coding being a nice touch, but still complicated to get information out of. The size of the image might play a part in that, and creating individual tables for the TCP/IP model, as well as each SCADA protocol might have proven to be a better method.
This group’s lab report had a great abstract. They let me know exactly what I am expecting to find within this lab report and what they set out to do during this process. Once again this group put an introduction into their lab report. Last time I stated that this was not necessary for the lab report, but this time I am looking at this from a standpoint pretending that I am someone that does not know a lot about the topics. I found that when I did that, I found that the introduction was good and made the lab report easier to follow and understand how the group organized their ideas. I hope that this group is not spending needed time creating this introduction. Like other groups, this group realized that they would be able to truncate the list that they made for the first lab report. Having this knowledge, it should make all groups happy that they had done the majority of the research for this part of the lab, assuming that the group put the time and effort into their research for the first lab exercise.
The most noticeable problem with this group’s table for active reconnaissance tools was the lack of any layer 0 tools. They included the extended layer of people or layer 8. Other groups found some kinetic tools but I liked that the group put problems that the tools on layer 8 could run into. Another problem I saw with this table was the placement of some of the tools into an OSI layer. Some of the tools had more than one location, for example MBSA. The group placed this tool in layers 4,5,6 and 7. The lab exercise stated that the tools must be placed into only 1 layer; the group should place the tool into the best layer, not any layer that it can go into. The group put all tables into the lab report at the end. This made for a little complicated reading. I would like to have seen the table, then the description afterwards. To me, this would have made the lab report a little more cohesive. One thing I found really interesting with this lab’s report was their issues section. No other group seemed to have the problems this group had. Does this mean that other groups did not do the same thing in their laboratory exercise? Two of the groups found that they found no issues or problems. The other two groups had some issues. It does not seem that all groups are performing the same tasks in the laboratory exercises. Once again, we are in the beginning of the lab exercises and I would like to see more cohesiveness in this group’s lab report. I think that it is noticeable that different people wrote different part of this lab report. I think maybe one person of the group should work on making all the different parts flow together better.
The literature again treats each article almost as an individual entity. Each paragraph of the beginning lit review treats only one article and gives a summary of the article’s contents. The authors don’t give any insight into the methodologies, omissions, or relation to the task at hand except for the last two paragraphs. The last two paragraphs of the literature review relate the content of the articles to the broader topic of penetration testing but only in terms of mentioning content in the articles that relates to penetration testing. The last part of the literature review mentions an article that further defines red-teaming in the context of a military exercise along with a brief statement saying that it “may be extended to test distributed computer systems.” These last two paragraphs would’ve read much better and provided the reader much more context for the lab exercises had they been expanded and provided greater detail of the subject matter mentioned in them.
The second portion of the methodologies section that mentioned how the group planned on splitting up the work was interesting to read as a fellow student. Seeing how other groups communicate internally and split up the work load, while not directly related to the lab exercises, helps get an insight into how the group works and adds depth to the methodology. The procedures section could be included with the methodology section, the both seem to discuss the same process. I like the inclusion of additional exploit tools in the lab exercises, using Backtrack alone would’ve introduced some bias into the tool selection process and it’s nice to see additional security tools evaluated. The explanation of the anonymity options was a little short. How were they tested? I agree with the conclusions regarding onion routing and proxies, those seem to be the predominant methods in the field and the inclusion of the link to freehaven.net is useful.
The headings used for the different section were a little difficult to follow since they all used the same formatting. Is TCP/IP part o f the “Results and Discussion” section? The results section about the active reconnaissance tools was interesting because it discussed the VoIP (SIP) and SNMP results as well as only covering the standard ping sweep and port scan results one would expect. The anonymization section was very well done and treated the problem from many different aspects including covert channels.
The TCP/IP layering discussion is rather brief but does handle both sides and makes the important point that the model is just that, a model. The argument was made in some of the literature that layering was harmful (http://tools.ietf.org/html/rfc3439) because it implies that the “functions of each layer are carried out completely before the protocol data unit is passed on to the next layer.”
The issue with classification of tools as “active reconnaissance” is an interesting problem when viewed in a larger context. The mention of the ‘passive’ compromised host serving as an active reconnaissance tool is interesting. Presumably the attacker would’ve had some involvement in the compromising of the host, thought that might not always be the case, but if the machine is blindly forwarding data (captured passwords, keystrokes, etc.) to a server somewhere, is that active or passive? Does it matter if the machine is sending the data using TCP or UDP?
Team 3’s abstract was excellent. They described their lab and how they were going to use it. Again as in their first lab I appreciated their introduction. It helped to better understand what we are trying to accomplish with this exercise. I liked how they organized their literature review. It made it very easy to read and understand how the articles tied back to the lab exercise. The methodology section was well written and the steps of the process of performing the lab were detailed. I thought they did a good job organizing their tables; however I did not see any tools listed in Layer 0. Some of the other groups were able to find recon tools at the layer 0 level. Also this group replicated some of their tools and put them into more than one layer. Their problems were well documented. The conclusions section in comparison to their lab 1 conclusion section was more comprehensive. Overall I thought their paper was well written.
This group starts off with an abstract that does a good job in introducing this lab paper. The abstract divides the lab up into two parts, examining active reconnaissance tools and the examination of SCADA protocols. The abstract covers all the parts of the lab and briefly explains what is to be expected in this lab. Next the group does an introduction to the second lab. In the introduction they begin by explaining that their research would be focused on active reconnaissance and that the use of a tool was examined better in the whole of the attack rather than individual events in the attack. They also defined active reconnaissance as having the components of: presence, risk, and limitation of scope. This start to the second lab does a great job in showing how the focus of the students should be at this point and to show how to be examining how to approach the research in this lab. The group goes on in the introduction describing the components given in the beginning of the introduction. In this description the group conveys that in active reconnaissance the attacker is known and that risk is closely associated to the presence of the attacker. Also the group conveys that there is a limit to the scope of this type of attack because information is sent in milliseconds, so the attack is a preparatory attack and that damages are the effects of the information gathered for the attack ahead of time. This is a very good leading up to the what this lab is about because it puts the reader into the mind set of what this lab is about and what this lab is trying to teach. The last part of the introduction explains what is going to be done in this lab. Next the group goes into the literature reviews. In the beginning of the literature reviews the group gives an introduction to what kind of articles are in the literature review. The group at first evaluates each article separately. In each evaluation of the articles the group describes the topic and theme of the article. They also point out some important points in each of the articles. I did not see any discussion of the research question, methodology, or supporting data or research. At the end of the literature review the group did discuss how the readings relate to each other and how they relate to the current lab nicely. At the very end of the literature review the group briefly mentioned that they did not see any errors or omissions. Next the group wrote up a methodology of the lab. The group stated that the table created in the first lab would be used throughout the rest of the labs. They said that they would pull the tools for the active recon table from that list. Also the group decided to use existing security tools to install in their virtual environment, because of the amount of tools available and that the tools have been reviewed in advanced. They also mentioned that they were going to divide up the work between the groups depending on the experience in that part of the lab. Next the group discussed the procedures. The group then took the tools from the first lab and eliminated tools in three passes. The first pass weeded out the obvious tools that were not active recon tools. The second pass consisted research on the remaining tools to further weed out any tools that could not be considered active recon. The last pass applied three criteria to each tool to see if it was an active tool or not, that criteria was presence, risk, and limited scope. This way of narrowing down the tools seemed to work nicely. This shows that the tools were well researched in how they function and how they will fit into these labs. Next the group tested several different tools in different environments including real network environments and virtual environments. The group then did an extensive research using specific web sites to examine techniques in anti-forensics. Last in the procedure section the team mentioned that they did research in the different types of SCADA protocols given in the lab and also details on the TCP/IP model, and that they aligned them to the OSI model. The group then reviewed the results of their findings. They started with the active reconnaissance tools. The group found that using a logical definition made categorizing the tools was a lot simpler. They listed several types of programs that they tested out. A couple of the types of tools did not go as they expected and explained that this could have been due to lack of experience in using those particular tools. Not a whole lot of information was discovered in testing these tools. They did find that most of the tools worked as they said they would and that proved that they could rely on using them in actual situations. Next they discussed anonymizing the attacker. The group explains that there is three ways to hide an attacker: proxies, obfuscation, and out-of-band communication. The group then does a good explanation of how each of these ways of hiding an attacker can be used. They even explain different ways that an attacker could use each of these methods to hide himself. They mention that the attacker could even use multiple methods to further hide the attack using an analogy of an onion. Next the group talks about the TCP/IP model that they chose. The group stayed with the four layer TCP/IP model. They argue that the TCP/IP model has to be able to handle any type of network so the physical layer doesn’t have any specific requirements. They do mention that some people argue that there should be a hardware layer but that they could not come up with a good explanation on why. They ended saying that this whole argument is a moot point anyway, because it is all just a model. Next they discuss the SCADA protocols. In each one of the descriptions the group does a good job in describing the protocol, but they do not explain any details of each of the layers. The group did all the protocols given by the lab and they also included Allen-Bradley’s DH+ protocol and the PROFIBUS protocol. The group then explains that even though most SCADA networks are separated from the internet, they can still be exploited through various methods including a specific tool they found. They also explain that even though the SCADA networks are more difficult to exploit the risks are much greater. As far as problems and issues the group found a few in categorizing active recon tools and the use of a beta version of Backtrack. In the conclusion of the lab they just quickly explained what they did in each of the steps of this lab. They did not give any type of explanation of what they learned from this lab. Last they showed the tables that were a result from the lab. The tables were well put together. The table with the tools categorized each active recon tool into the different OSI model layers and also aligned them with McCumber’s cube. The table of the SCADA protocols was nicely put together also. The table shows each protocol in comparison with the others and even categorizes them in color.
Overall team 3 had a great improvement over the first lab. They started off with the abstract and created a strong abstract that explain what was going to happen in the lab and what was some information going forward. Next they gave an introduction to their thoughts on what active reconnaissance, and limitation of scope. Which gives the question; are there other variables that can affect the reconnaissance? Would skill set take a role in how active reconnaissance would be not only used but implemented? The lab then goes to the literature and first gives an overview of all of the readings for this lab and gives the common theme. Then they break each article/ paper down and review them and how they relate to the class. The literature reviews where well done and gave an understanding to each of the subjects and how they would relate to class. But upon further discussion we where notified that the literature review was to be more cohesive and blend with each other. Each week is a learning process and the team’s labs are getting better. The group then goes onto their methodologies and discusses what tools where used upon the actual hands on part of the lab in the virtual environment. They described using Backtrack 4 BETA. Later on they will have in the issues that they encountered problems using Backtrack 4 BETA. Which gives a question should we rely on a beta version of a program? Are their benefits that trying to use a new version that just might not be ready then the final release of Backtrack 3? I commend them in trying to use the newer version because some information may have been differently obtain using the beta and what they got when using the Backtrack 3. This information could have been used within their lab. Yes it might have failed but what was gain from the experience? After this the lab goes onto the SCADA protocols and the TCP/IP comparison and their version of the table. They explained each aspect of the tables and where able to explain why the different layers where placed at where they where. It seems like each group has these protocols in different areas still. Is it possible that it can be argued where certain protocols lie on these tables and why? The tables are at the end of the document and where put together in a clean fashion and where easy to read. The teams then goes onto define their issues with the lab about ambiguity and exploitation and then the issues they had with Backtrack 4. They then conclude on what was experience with in the lab and what had been gained. One thing that I did miss was any findings they may have had from their results with the testing they explained well how they where going to implement but when it came to the results I wanted to know more. Their where minor issues that created and overall good lab which made the reader ask questions and get involve.
The team’s abstract is clear and they identify everything that is they are going to discuses in this lab. The team then goes on with a strong introduction, which so far is the only team to have an introduction for there lab. Within there introduction they identify the limitation of the scope.
In the literature reviews they mention that it is necessary to define goals, just as the other groups, for the reading of About Penetration Testing by Mat Bishop. Agreed, that define goals are important part when conducting projects such as penetration testing. What do you hope to get out of this test? This would be an acceptable goal when conducting a penetration test. The team, is one of three to leave out the example about the police officer attempting to break-into the car to see the different forms of attacks an attacker may take. This seem somewhat worth mentioning only because the author did use the analogy several times throughout the paper. Ethical hackers are described as penetration testers but are they? Perhaps a penetration tester is someone who knows how to use certain tools to exploit certain systems. They can be considered ethical because they are instructed to do so by they the client. Perhaps they are just an ethical worker, maybe this person was trained on how to push a button but not much more than that? I could drive a car does not mean I know how to repair a ball joint. The team then goes on to talk about Black, White and Gray box model of ethical hacking. In the methods the group talked about gathering active reconnaissance tools from the list they already made in lab 1, which is great since it was said that lab 1 is the basics for the research for this exercise. The teams then goes on to talk greatly about SCADA an SCADA protocols. In the teams problems and issues they were the only team to mention about using Backtrack 4 Beta. Since Backtrack 4 Beta was release, the stability was not stable which why Backtrack 3 final is a more stable and reliable choice.
I think that group 3’s write-up for lab 2 was decent. The abstract for this lab was very good. The literary review was somewhat poor. Group 3 did not answer all of the required questions for the literature review. They did not explain the research methodology, how it relates to the laboratory or whether or not they agreed with the readings. All of the citing for the literary review was adequate. The literature review was cited properly except when including page numbers. The table containing the penetration testing tools was adequate. More depth could have been put into how these tools are actually installed. What if you needed to make your own Live CD or install these on a computer that BackTrack is not compatible with? I think the group did well when actually discussing why they chose the 4-layer TCP/IP model. However, do these layers match up exactly with the OSI model? Or is it fuzzy where layers like the session and transport layers meet? When dealing with SCADA, what about the Kinetic layer? When dealing with the DeviceNet protocol, what about the Pseudo Transport Layer? Is it really its own layer or does it exist in another layer? I liked how the group included a section discussing the exploitability of SCADA. The conclusion to this laboratory was also well done because it accurately sums up their procedures and findings.
Within the abstract team three gave a brief overview of the laboratory assignment. Unlike other groups team 3 referred to the virtual lab environment that was created with a series of virtual machines as a mock-up penetration testing environment.
Group 3 included an impressive introduction section as they did in their previous lab. The group went on to say that active reconnaissance tools defines the scope of what the tools are to do and described the concept of presence to risk , for the lab wanted the groups to find tools that would give an attacker anonymity on a victim’s network. The introduction also mentioned SCADA protocols and that the groups are ultimately aligning their layers to that of network models to figure out what tools could exploit the SCADA protocols.
Within the literature review section, group three needed to relate each of the articles to relate the articles to each other and address the methodology used within the articles. The summary for Automated Red Teaming: A Proposed Framework for Military Applications appeared to be too brief. The group did a good job relating the articles to the laboratory assignment by applying the general concepts from the articles to penetration testing. I had to partially disagree with the statement “The type of penetration testing we are using in this course would fit into the white box model due to our detailed knowledge of the target system” because while we know about the systems we are targeting, we are also using tools that would be more black box orientated. Group three did not find any apparent errors or discrepancies within the literature review.
In the methodology section, group 3 also used the table from the first lab to aid in the collection of active reconnaissance tools. Group three used tools that were already pre-loaded onto images that would be used within the virtual environment. Group 3’s laboratory environment differs from the other groups in that they have installed tool collection such as The ‘Backtrack’ and ‘Knoppix-STD’ on a live network with real hardware and in a virtual environment as well.
In regards to the subject of anonymity of an attacker on a victim network, group three described a few techniques such as proxies, obfuscation, and ‘out-of-band’ communications. The group pointed out the caveat about proxies was that while they are effective in hiding the origin of connections, the traffic generated could easily be spotted on a network.
In the OSI and TCP/IP alignment section team three sided with those who think the TCP/IP model should have only four layers. I have to agree with the group’s statement “In reality, it’s a moot point the model is just that, a model. It is designed to visualize the communication process between two networked devices.”
In the SCADA protocol section of the laboratory report group three besides describing MODBUS, DNP3, and DeviceNet SCADA protocols also researched DH+ and Profibus. The group went on to describe some exploits to SCADA protocols such as CitecSCADA exploit.
In the issue section team three stated that they had a couple problems. The first was the ambiguities associated with classifying an exploit tool as an ‘active reconnaissance’ type. The second problem was stability problems encountered with the ‘BackTrack 4 Beta’ release used for the tool-utilization test machines.
@nbakker: We said we couldn’t find Stallings’ reason, not that there wasn’t one. TCP port 502 is a default, not the answer to the equation.
@shumpfer: Like TCP/IP, the SCADA protocol stacks are models. There is a lot of overlap in functionality, so yes, you can argue it differently depending on your point of view.
@chaveza: The spelling and grammar check in Word is your friend.
@prennick: We did cover the kinetic layer in SCADA, it’s in the chart. We agree with you about the ambiguity of the layers, and made the point with TCP/IP. Perhaps we should have been clearer with the idea that the point extends to all models.
Thank you to everyone who gave criticism rather than just summarizing. Your feedback is helpful.