TECH 581 W Computer Network Operations: Laboratory 2, Team 5

Abstract

Active reconnaissance is a method used by attackers to footprint a remote system by actively probing the network for information and getting results back.  This method risks exposing the attacker and steps can be made to obscure the source of the probes but the tools that do so may provide unreliable results to the attacker.  Tools used for active reconnaissance will be aligned with the OSI and TCP/IP models and their McCumber cube coordinates.

In this lab we also look at a comparison of the TCP/IP protocol, SCADA protocols, and the OSI 7 layer model and analyze the potential risks of merging TCP/IP networks with SCADA networks.  By analyzing the tools used to probe a TCP/IP network, we can see how a SCADA network could also be probed for information and vulnerabilities to be used by an attacker.

Literature Review

Red-teaming is a term that originated in military exercises.  The exercise would be to place two opposing teams, the red team and the blue team, against each other, the red team usually playing the part of the adversary.  The goal of the red team would be to exploit holes in the blue team’s operational strategies with the overall goal of the exercise to improve the blue team’s tactics and response to an adversary’s actions (Choo, Chua, & Tay, 2007).  There are many ways to adopt and apply these principles to information security as a whole.  Application developers who wish to test the security of their applications can use tools like fuzzers which input various types of data into applications looking for holes or weaknesses in the program’s error handling routines (Godefroid, Kiezun, & Levin, 2008) essentially turning the developer or whoever is doing the testing into a red team.

One tool a red team may use in the planning stages of their attack is an attack tree.  Attack trees are a way to define the goals of the penetration testing exercise and map out various ways to get there.  The complexities of computer systems have led to the development of attack models such as those described in (Singh, Lyons, & Nicol, 2004) which describe mathematical equations for determining the number of ways a system can be targeted.  The example shown in (McDermott, 2000, p. 16) for opening a safe is an excellent way of graphically showing how a tester needs to think.  Sometimes the goal of the attack may have limitations or caveats, taking the example of opening the safe, the attacker could blow open the safe but if their goal is to do so without detection, they’ll need to investigate other methods of gaining entry.  The same principles apply when performing attacks or simulated attacks on computer systems.  An attacker may or may not wish to make their presence known and those goals will determine which tools they’ll use during their reconnaissance phase and attack phase.

Active reconnaissance is one of the many tools an ethical hacker or penetration tester may use when footprinting a system.   Active reconnaissance is risky for the attacker because they are actively probing for the information and likely exposing the source of those attacks but the information gathered can often be worth the risk.  Surreptitious active reconnaissance would be the holy grail of footprinting activities and is achievable in limited capacity thanks to project such as Tor which obscures the source of network traffic.  Another method of obscuring reconnaissance traffic would be to set up an IP reflector, typically used in Distributed Denial of Service attacks as described in (Jin, Wang, & Shin, 2003) except the attacker could control both endpoints and use the target’s network as the reflection point.  Active reconnaissance also raises many ethical issues for the tester as they will be actively engaged in a simulated attack against their customer.  (Hafele, 2004) describes the issues with disclosing the testing to network staff and the effects on test outcomes.  Providing little information to the attackers can be part of the test exercises.  By gauging the ease with which the tester can acquire information about a target’s system, an organization can make a decision on how to deal with those risks (Bishop, 2007a, pp. 84-85).

Because of the ethical issues surrounding penetration testing, strict care needs to be taken that the test is only run against the desired target’s systems.  A process for this is outlined in (Bishop, 2007b) and we utilized a similar method in our lab environment.  By leaving the virtual environment segmented from the rest of the network we minimize the effects of our active reconnaissance tests, especially since the desired effects of those is to go as far and wide as possible.  In order to transfer tools in and out we utilized the Citrix client drive mapping functionality to server as our file transfer medium.

Supervisory Control and Data Acquisition (SCADA) networks also utilize network protocols to communicate, many incorporated into TCP/IP networks.  Because so many of the tools used in penetration testing and active reconnaissance operate in the network layers of the OSI model they can be applied to discovery and exploitation of SCADA networks as well.  A penetration tester needs to watch for the presence of SCADA networks and include them in the test plans and attack trees.  Oftentimes a failure in a SCADA network can lead to kinetic results, penetration tests that ignore SCADA networks are placing the target organizations in serious risk.  An analysis of SCADA protocols such as MODBUS and DNP3 show similar layering as TCP/IP and therefore can be mapped to the OSI model.  SCADA penetration testing labs can also be created similar to the labs created for our testing of network reconnaissance tools.  A SCADA test lab would require specialized hardware as described in (Annarita et al., 2008) for full scale testing of the Remote Terminal Units and other components but testing of the control software all the way down to layer two is possible with the right software in a virtualized laboratory environment.

The OSI model has provided the categorization for many of the tools examined in this exercise.  Due to the overwhelming popularity of the TCP/IP protocol in most networks as well as the merging of SCADA protocols with the TCP/IP protocol, matching the layers of the OSI model with the TCP/IP model will allow us to fit the tools discovered for each OSI layer with their corresponding TCP/IP layer.  The TCP/IP model is only five layers compared to OSI’s seven layers, they are Application, Transport, Internet, Network Interface, and Hardware (Comer, 2000, p. 184; Stallings, 1997, p. 35) outlined in Table 2.1.  The RFC for the Internet Model of which TCP/IP is a part only describes the first four layers outlined by Comer and Stallings, omitting hardware(Requirements for Internet Hosts – Communication Layers, 1989).  The concept of layering breaks up the stack into logical pieces, each of which communicates with their corresponding layer at the receiving end by passing the data down the stack, a four layer model omits the requisite physical connection and its protocols that facilitate the connection.  Comer describes the hardware layer as the layer that the other four layers build upon.

Methodology

The first part of this lab required installing tools that actively probe the network.  We performed this using our virtual lab environment as well as our own personal computers on our private home networks. After building the table of active reconnaissance tools we identified the most commonly targeted layers by the number of tools available for each.  We then selected a few tools from each layer and sought out to actively examine surrounding network hosts.  We intend to use tools such as SolarWinds MAC Address Discovery, combined with Ping Sweeps and port scans using nmap to determine the number of hosts on a given network, their IP addresses, and an approximation of why type they were based on the ports they had open.  The MAC address tool will also allow us to reference the manufacturer of the network interface card giving us more avenues for future attacks.  In order to attempt obfuscation of our attempts we intend to use our personal equipment and Internet connections and utilize the Tor routing network.  This will obscure the source IP of the traffic and allow us to change source IPs quickly by hopping different Tor exit nodes.

The second part of the lab was to create tables that compared the relations between the OSI 7 Layer model, TCP, and some SCADA protocols. When researching the SCADA protocols a paper was found on various forms of the MODBUS protocol and attack trees called The Use of Attack Trees in Assessing Vulnerabilities in SCADA systems(Byres, Franz, & Miller, 2004).  Within this paper they compared the OSI and MODBUS and their table became the basis for comparisons.  MODBUS was created in the late 1970’s by Modicon Corporation that allowed its line of industrial PLCS. The MODBUS has three different physical layer options because of when they became available.  These different MODBUS options are client/server structures and originally was a only a 2 layer stack. From reading more about the MODBUS protocol it relates with the OSI model in the matter that it breaks down into different layers and at the lower layers detection is low due to where attacks will fall on the model.  From the first lab tools where found and related to the OSI model and at the layers it becomes easier to avoid detection. An example would be someone using a “Can-tenna”. This is a homemade device that is usually made out of a metal can of varying sizes and without much effort can disrupt a signal compromising data over a network. Not all SCADA protocols are like MODBUS and operate at the lower levels. DNP3 will operate up at the Application layer of the OSI model along with the MODBUS TCP and Transport Transmission Control Protocol. Protocols define the rules by which devices talk with each other, and DNP3 is a protocol for transmission of data from point A to point B using serial and IP communications (Curtis, 2005).  In short this means that it uses TCP/IP to get from one node to the next for many different tools on the internet such as messaging, html, and other. Essentially it breaks down the regular TCP/IP model and makes it smaller and then the actual protocol is small for a more reliable form of data transfer.  From the paper it was assumed that more utility companies use this protocol between master and slave devices for communication. Devicenet is a SCADA protocol that also operates more at the application layer of the OSI model. This protocol allows for small microcontrollers to use a system called Controlled Area Networking or CAN for short. This does not include the processes of the protocol at the lower levels. But for the lower level it uses CIP or Communication and Information Protocol this allows for every device to be looked at like a series of objects. Using this SCADA protocol allows for different types of messaging with various devices. Device net would information exchange, large I/O networks, and safety devices. An issue for all these protocols is converting them into other forms and having a wide range of protocols is has both good and bad sides. The good side is that it allows for a more secure system if many people do not use the protocol and in fact do not know it exists. It also allows for the companies to perfect their systems to their needs just like a company might have software that is made just for their use and not use at any other company in the world. On the other hand it can also be a problem with engineers not knowing the protocols and if they do not know them the same reason for keeping others out will create their own denial of service against the company.

Findings

The tools used in active reconnaissance heavily focus on layers seven, four, and three of the OSI model as seen in Table 1.  Because the VMWare virtual hosts use virtualized NICs they have a common MAC addressing scheme that allows us to recognize that they are running in VMWare though they can be easily changed in some virtualization environments to hide this.  MAC address probes against PCs provided us with the manufacturer of the NIC card.   Obfuscating our scanning traffic using Tor proved slow and unreliable.  Some port scans would simply time out due to the speed of the Tor node we were using, this resulted in inconclusive results because we weren’t sure if the port being probed was down or just timing out.

With the information found on the different SCADA protocols these are positives and negatives to all of them and the way that they fall within the OSI model changes from each protocol.  Tables 2.2 through 2.6 show the relationship of five SCADA protocols with the TCP/IP five layer model and the OSI seven layer model.  With creating the tables it also allows for more informed penetration testing and the knowledge on where to attack each system. Some of the systems would focus on the lower levels and disrupting these would cause a successful attack against the system. While attack some others such as the Devicenet will cause problems at the higher levels with the applications making it that the terminals would not be able to communicate.   Protocols with higher complexity and numbers of layers such as the difference between MODBUS+ and MODBUS on TCP add more points of attack specifically since the integrate TCP/IP.

Issues

The BackTrack 3 VM image provided by the BackTrack team had an older version of VMWare Tools loaded in it which prevented networking from functioning properly.  In order to fix this we loaded the new version of VMWare tools by running the “Install VMWare Tools” function from within VMWare Workstation which mounts a virtual CD image in the VM.  We extracted the files from the TAR file and ran the install script.  After rebooting the network interface worked properly.

Conclusion

Active reconnaissance is a risky tool for an attacker to use and attempts to obfuscate the traffic using proxies or Tor provide unreliable results.  Any attacker serious enough about gaining worthwhile results from active reconnaissance would be better served running the attack from a compromised machine.   While this still doesn’t provide complete anonymity, it adds another layer of complexity to the attack that would need to be resolved by those investigating the attacks.  Reading the articles provided for the lab in addition to the articles found on the internet gave a better understanding of the penetration testing, ethics, the relation of tools to the McCumber cube coordinates, and the creation of the table comparing the various protocols to the OSI 7 Layer model. For the first part of the lab reconnaissance and applying different attack methods to the protocols provided results needed for comparing the various tools and exploits to the McCumber cube coordinates. Upon working on the second step of the lab information gathered from the previous step allowed for the creation of the tables for the comparison tables. This information provided a tangible view on how other protocols may or may not fit within the OSI 7 Layer model.

SCADA protocols are quickly being merged with TCP/IP to provide more uniform access across a network and this gives attackers an opportunity to extend the range of their attacks in to the physical world.  With the relative ease seen in discovering hosts on a TCP/IP network, these principles could be extended to examining and probing a SCADA network.  The literature on SCADA network security details a need for examination of SCADA software and hardware that, as it comes on the network, it’s exposed to significantly more threats.  In contrast, the greater exposure will hopefully expedite the security review process and force hardware and software vendors to perform better security analysis on their products using red teaming methods.

Table 1

OSI Layer Active Recon Exploit McCumber Cube Coordinates
Layer 8
People
Phishing, Social Engineering, Spy Confidentiality, Storage, People
Layer 7
Application
Cisco Torch, Fierce, GFI LanGuard NSS, httprint, Hydra, Maltego, Metoscan, Nessus, Nikto, Nmbscan, Relay Scan, Security Administrator’s Tool for Analyzing Networks, Security Auditor’s Research Assistant, Solarwinds DNS Audit, Solarwinds DNS/WhoIs Resolver, Solarwinds Network Sonar, Solarwinds SNMP Sweep, XProbe2 Confidentiality, Storage, Technology
Layer 6
Presentation
THCSSLCheck Confidentiality, Storage, Technology
Layer 5
Session
Smap Confidentiality, Storage, Technology
Layer 4
Transport
Amap, Firewalk, Scanrand, SinFP, Solarwinds Port Scan, SuperScan, UnicornScan Confidentiality, Storage, Technology
Layer 3
Network
Angry IP Scanner, AutoscanAutonomous System Scanner, Cisco OCS Mass Scanner, Fping, hping, IKE-Scan, netdiscover, nmap, Protos, Sing, Solarwinds IP Network Browser, Solarwinds Subnet List, Solarwinds Ping, Solarwinds Ping Sweep, Confidentiality, Storage, Technology
Layer 2
Data Link
Solarwinds MAC Address Discovery, Solarwinds Switchport Mapper, VoIP Hopper Confidentiality, Storage, Technology
Layer 1
Physical
Fiber tap, Wiretap Confidentiality, Transmission, Technology
Layer 0
Kinetic

Table 2.1

OSI with TCP/IP

OSI

TCP/IP

Layer 7
Application

Application

Layer 6
Presentation

Layer 5
Session

Layer 4
Transport

Transport

Layer 3
Network

Internet

Layer 2
Data link

Data Link

Layer 1
Physical

(Hardware)

Table 2.2

OSI, TCP/IP, and DNP3

OSI

TCP/IP

DNP31

Layer 7
Application

Application

Application

Layer 6
Presentation

Layer 5
Session

Layer 4
Transport


Transport

Pseudo Transport

Layer 3
Network


Network

Layer 2
Data link


Data link

Link Layer

Layer 1
Physical


Hardware

Physical

1 http://www.dnp.org/About/DNP3%20Primer%20Rev%20A.pdf

Table 2.3

OSI, TCP/IP, and DeviceNet

OSI

TCP/IP

DeviceNet1

Layer 7
Application

Application

CIP Application

Layer 6
Presentation

CIP Data Management and I/O

Layer 5
Session

CIP Message Routing and Connection Management

Layer 4
Transport


Transport

DeviceNet Transport

Layer 3
Network


Network

Layer 2
Data link


Data link

Controller Area Network CSMA/CD

Layer 1
Physical


Hardware

DeviceNet Physical Layer

1 http://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00026R1.pdf

Table 2.4

OSI, TCP/IP, and MODBUS on TCP

OSI

TCP/IP

MODBUS on TCP1

Layer 7
Application

Application

Application

Layer 6
Presentation

Modbus on TCP

Layer 5
Session

Layer 4
Transport


Transport

Transport

Layer 3
Network


Network

Network

Layer 2
Data link


Data link

Data link

Layer 1
Physical


Hardware

Physical

1http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

Table 2.5

OSI, TCP/IP, and MODBUS+

OSI

TCP/IP

MODBUS+1

Layer 7
Application

Application

Application

Layer 6
Presentation

Layer 5
Session

Layer 4
Transport

Transport

Layer 3
Network

Network

Layer 2
Data link

Data link

HDLC

Layer 1
Physical

Hardware

Physical

1http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

Table 2.6

OSI, TCP/IP, and RP570

OSI

TCP/IP

RP5701

Layer 7
Application

Application

Application

Layer 6
Presentation

Layer 5
Session

Layer 4
Transport

Transport

Link

Layer 3
Network

Network

Layer 2
Data link

Data link

Layer 1
Physical

Hardware

Physical

1http://www.serialmon.com/protocols/rp570.html

Works Cited

Annarita, G., Gabor, K., Tanya, R., Aakash, S., Bruno, S., & Jon, W. (2008). A Testbed for Secure and Robust SCADA Systems. SIGBED Rev., 5(2), 1-4.

Bishop, M. (2007a). About Penetration Testing. Security & Privacy, IEEE, 5(6), 84-87.

Bishop, M. (2007b). Security Plan for Red Team Testing.

Byres, E. J., Franz, M., & Miller, D. (2004). The Use of Attack Trees in Assessing Vulnerabilities in SCADA Systems.

Choo, C. S., Chua, C. L., & Tay, S.-H. V. (2007). Automated Red Teaming: a Proposed Framework for Military Application. Paper presented at the Proceedings of the 9th annual conference on Genetic and evolutionary computation.

Comer, D. E. (2000). Internetworking with TCP/IP, Volume 1: Principles, Protocols, and Architectures, Fourth Edition: Prentice Hall PTR.

Curtis, K. (2005). A DNP3 Protocol Primer. DNP Users Group.

Godefroid, P., Kiezun, A., & Levin, M. Y. (2008). Grammar-based Whitebox Fuzzing. Paper presented at the Proceedings of the 2008 ACM SIGPLAN Conference on Programming Language Design and Implementation.

Hafele, D. M. (2004). Three Different Shades of Ethical Hacking: Black, White and Gray. SANS Institute.

Jin, C., Wang, H., & Shin, K. G. (2003). Hop-count Filtering: an Effective Defense Against Spoofed DDoS Traffic. Paper presented at the Proceedings of the 10th ACM Conference on Computer and Communications Security.

McDermott, J. P. (2000). Attack Net Penetration Testing. Paper presented at the Proceedings of the 2000 Workshop on New Security Paradigms.

Requirements for Internet Hosts – Communication Layers. (1989). RFC Editor.

Singh, S., Lyons, J., & Nicol, D. M. (2004). Fast Model-based Penetration Testing. Paper presented at the Proceedings of the 36th Conference on Winter Simulation.

Stallings, W. (1997). Data and computer communications (8th ed.): Prentice-Hall, Inc.

12 comments for “TECH 581 W Computer Network Operations: Laboratory 2, Team 5

  1. nbakker
    June 23, 2009 at 7:08 pm

    Team five has presented a complete and concise lab that details the procedure as was expected by the lab design document. A lab that meets almost all of the requirements as per the syllabus and lab design document. The abstract meets the requirements of the syllabus as for length, and does give an overview of what will be accomplished in the lab. The literature review is more cohesive then any of the other labs presented, including team two’s literature review. The literature review does more than just list articles with an explanation of the article. There is a high level of synthesis between the articles, but even though this is the case, it still reads slightly like a list of categories instead of just articles. The methods section lists all of the tasks that will be completed in the lab, and is rather long and complete, but I still question it as showing a scholarly strategy and technique for completing the lab. The methods section appears to include information that might somewhat be better served in the findings section. Team five appears to assume the five-layer TCP/IP model over the four-layer without any reason over that Comer and Stalling say that the TCP/IP model might be five layers instead of four. I disagree with this as before, until the DoD changes the model, the TCP/IP model is four layers. This team also does seem to not give a reference to source anonymity other than in their conclusion, and even than that reference is just two sentences long, they also do not provide any reference to professor Liles blog as a source for those two sentences which calls the completeness of their lab. Team five shows an active recon table that while seemingly balanced does not agree with other teams at layers other than 3, 4, and 7. This might be an omission on the part of team five, and it might also suggest a deeper understanding than the other teams on active recon. The SCADA tables shown by team five are very easy to read, and are broken into separate tables for each SCADA protocol making them easy to get information from, and form possible attack vectors. Team fives tables on MODBUS and RP750 agree with team two’s tables on the same. As I stated before I disagree with their almost assumption of the five-layer TCP/IP model, however I do agree with their SCADA tables in their entirety. Team five’s approach is different than team one’s approach, as well as team fours approach. It does appear to align with team two and team three’s approach to this lab. I do not believe team five could provide much improvement over that which has been already stated. Team five’s methods do not however require improvement. All in all team five has presented an answer to lab two that is efficient, mostly complete, and represents an understanding of the requirements of the class and lab that is well developed. However it was not without its room for improvement.

  2. mvanbode
    June 23, 2009 at 10:39 pm

    Once item I noticed right away was that this group had a much more cohesive literature review. It did not sound like a list like the majority of the other group’s la reports did. Even though the literature review was more cohesive, not all of the questions that a literature should have were answered. The second methodology paragraph was long. I feel that it should have been broken up into more paragraphs to properly convey the different models that were being compared to each other as well as the OSI 7 layer model and the TCP/IP model. The group did not put the tables created into the findings section. I feel that the table belongs there more than at the end for a more cohesive paper. In addition to that, I think that the discussion of the SCADA models as well as a lot of the methodology section should be put into the results section since it is a result of research. If the group had done this, I feel the lab report would have more cohesive. It seemed to go from place to place and one could tell that different people wrote different parts of the lab report.
    The group’s table was well structured except that the kinetic layer had no tools in it. Does the team think that there are no tools for this layer, or is the table incomplete? Like the last lab report from this group had a fantastic layout for the table, making it much easier to read than most of the other groups’. I like having one layer with all of the tools in it. It is much easier on the eyes because there are fewer words. The group discussed the why the TCP/IP model could have 4 or 5 layers. There was not a real clear answer as to what side of the debate the group was on. They did include all 5 layers in their comparison tables, but never stated why they chose what they did. Overall the group wrote a much better lab report than they did for the first lab report. I would just like to see more cohesiveness in future lab reports and maybe sectioning out tables and then discuss them right after in the results section.

  3. mafaulkn
    June 24, 2009 at 8:56 am

    Team 5’s abstract was well written and gave a solid definition of what active reconnaissance is and it can be used by hackers. It also met the requirements detailed in the syllabus. They explained how the tools used for active reconnaissance will fit into the OSI and TCP/IP module and their McCumber cube hierarchy. There lit review was well organized and encompassed what the authors were trying to express in their writings. I thought the way team 5 put the tables together by grouping all the tools that share the same OSI layer and McCumber cube was good. This made the table easy to follow. I didn’t see any tools in layer 0; where as some of the other groups did indentify at least a few tools. The method section was very detailed but maybe a bit too long. I agree with their findings issues and conclusions. Overall the paper and lab was well done.

  4. jeikenbe
    June 24, 2009 at 11:53 am

    In this group’s abstract they introduced the idea of active reconnaissance but did not define what it was. They also introduced anti-forensics and how it can help in hiding the attacker but also at the same time can be unreliable. They also talk about making the active recon tool table and aligning it to the OSI model and McCumber’s cube. The last part of the abstract talks about the comparison of the TCP/IP model and SCADA models. They mention that there is a risk when SCADA networks are merged with TCP/IP networks. This also leads into the ability to study ways to probe TCP/IP networks to also probe SCADA networks for information. Next the group goes into their literature review. The team goes about literature different from the rest of the groups. They do not talk about each individual article, but incorporate each article into an explanation of active reconnaissance in red teaming. The team does a good job in intertwining how each of the articles in this lab with each step in the lab. They do a great job in how they both relate. The review also gives a brief explanation of what each article’s theme is about in a circuitous way. The team did not though talk about the methodology, research question, supporting data, or errors or omissions of each article. Next the group discusses their methodology for this lab. They begin by explaining how they will use various active recon tools to gather information about a network. They also explain how they will use Tor to cover their tracks. They do a nice job of explaining the tools that they will use to do the attacks and how they will use them, but it almost sounds like they are going to be limited on the number of tools they are going have at their exposal. They also only very briefly talked about the table that they built for the active recon tools. Next in the methodology the group talks about the second part of the lab. I think that they went into too much information about the protocols at this point in the paper. The team starts explaining the MODBUS protocol and how it can be compromised and they also start talking about other SCADA protocols in detail also. This part does not define the methodology of that section of the lab. The description of the SCADA protocols should have been in a part of its own and should have gone on describing the different layers of each of the SCADA protocols. The group also forgot to talk about the other SCADA protocols they give in the table at the end of the lab paper. Next the group talks about their findings. The group mentions that the active recon tools focus on layers seven, four, and three of the OSI model. They also mentioned how they did scans to gain information on the MAC addresses of the computers and that they had troubles running their scans through the Tor network. As for the findings in the second part of the lab, the group talked about the SCADA protocols fall within the OSI model and how creating the tables for the SCADA protocols gave the team a better insight on how to attack SCADA networks. Next the team explains that they had some problems with Backtrack working properly in VMware and how they solved the problem. Last the team concludes the paper by explaining how active reconnaissance can very risky. They mention that it is better to use compromised machines to do the dirty work than trying to cover up your tracks. The team also mentions how the articles were very insightful in giving them a better understanding of how each tool fits into the OSI model and McCumber’s cube. In the last part of the conclusion the team talks about how SCADA networks are becoming more incorporated into the TCP/IP network and the dangers of this. They mention that more security analysis needs to be done on SCADA hardware and software to prevent these security risks.

  5. gdekkerj
    June 24, 2009 at 3:31 pm

    I find this lab write up to be very well assembled and researched. Not only is the literature review remarkably clear and concise, it is written very ‘smoothly’ in that issues directly related the lab are integrated and discussed without any discernable change of tone or topic-very nice. I also found the description of the ‘experiments’ done with the tools very interesting. I would judge the tool listing to be nearly impeccable, with perhaps one small contention which I shall discuss later. The discussion of SCADA protocols was generally well done: I thought the concise and to-the-point discussion of the different aspects of SCADA to be appropriate. I feel both the ‘Findings’ and ‘Conclusions’ section to be well considered. I also appreciated the brief discussion of problems and issues encountered in the lab.

    A small number of minor flaws were present in this write up which must be mentioned. I thought the second paragraph of the ‘Methodology’ section, the one which discussed SCADA, to be poorly formatted. This large chunk of information would have been greatly improved in presentation by breaking it up into smaller, internally consistent paragraphs. As it is now, it ‘reads’ roughly, and has all the characteristics of the classic ‘run-on’ paragraph denounced by composition instructors. This is an issue easily corrected: something to consider for the next lab write up.

    Additionally, I must discuss the inclusion of ‘Solarwinds DNS/Whois Resolver’ among the ‘active’ reconnaissance list. According to the description (via the link helpfully provided) I think the tool to have ‘extremely’ limited active reconnaissance capabilities ( the ability to ‘ping’ a host to verify that it is up) with the much greater emphasis on what I would judge to be ‘passive’ data gathering via DNS queries. I cannot fault this group technically for including this tool, as it does in some regard engage the target network, put if the only ‘active’ functionality is a ‘ping’ variant, does it really belong in OSI layer seven? I suggest, ‘despite’ this tools name, it probably belongs in layer three or four. This is a relatively minor criticism, but I think it serves well in demonstrating the ambiguities present in classifying some of these tools.

    Finally, I wish to discuss some of the more interesting findings presented. I found the experiment with Tor a very thorough touch, though I noticed that the ‘Conclusions’ section asserted “using proxies or Tor provide[d] unreliable results,” yet any recounting of using a ‘straight proxy’ (which is certainly different than Tor) is not present. Did you try a simple proxy, or are ‘Tor’ and ‘proxy’ being considered the same thing in this statement? In my opinion, Tor only serves the purpose of providing privacy to the public at large, to those who have no other recourse: a truly malicious attacker will not worry about the legal consequences of creating privately controlled proxies by nefarious means. These illegally controlled private proxies are ‘much’ more desirable to a malicious attacker due to the fact that they are effectively under his complete control. It is also true that these illegal (and unwilling) proxies can be expendable in an attack, so complicated encryption and routing techniques need not be used-almost certainly assuring greater reliability than the Tor network. A nice experimental touch, though, and I would be curious to see further results in this area of inquiry.

  6. Borton
    June 24, 2009 at 4:28 pm

    Team five starts with a concise abstract. Unfortunately it goes down hill from there. The team’s Literature review says very little in spite of being verbose. You relate the articles back to the lab, but you really don’t review them in depth, and you don’t evaluate. Did you cover all the articles? It feels like something is missing. There are two really nice paragraphs at the end of the literature review that don’t fit with the rest of the section. They might make a nice introduction, or beginning to the methods section. Likely they should have been part of the methods section, since this is the only place the group ever discusses TCP/IP. I don’t follow the discussion of SCADA at all. You talk about upper and lower layers, but don’t really go into detail. It doesn’t make much sense. Tell me about each protocol and how the layers work together. Compare it in detail to TCP/IP or OSI. It would have been nice to see all the SCADA protocols in one table. Did you look at any other protocols? Did you ever decide how many layers are in the TCP/IP stack? What is the evidence? The results section as well as the conclusion is also thin. The only thing I got out of reading the lab is that TOR and proxies didn’t work well with active scanning. Did you try slowing the scan? Give me more detail about everything.

  7. dkender
    June 24, 2009 at 4:31 pm

    I believe this was overall a well-written lab report. I found it interesting that they discussed using an IP reflector as part of their surreptitious active reconnaissance. I also think that their explanation for the need to include SCADA in their network testing is very good.
    Unfortunately, due to my work schedule the past few days I was unable to furnish a more thorough review.

  8. dkender
    June 24, 2009 at 4:31 pm

    I reviewed the lab report for Team 4 and found that I agree with most of it. I do think that needed to take the time to proofread the document before submitting it. They would have also done well to run spell check grammar check.
    Unfortunately, due to my work schedule the past few days I was unable to furnish a more thorough review.

  9. prennick
    June 24, 2009 at 4:37 pm

    I think that group 5’s write-up for lab 2 was adequate. The abstract for this lab was very good. The literary review was adequate. Group 5 chose to write the literature review as one big comprehensive review, which is good. However, the group really did not discuss how the reading related to the lab, and did not discuss whether or not they agreed with each reading. It seemed as if the literary review was mostly a summary of all of the readings. All of the citing for the literary review was done well. 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 could have gone into more depth about why they chose the 5-layer TCP/IP model. When I say “more depth” I mean they should have indicated what which model they chose and why. They simply used the 5-layer model in the chart and did not discuss any of the possibilities for a 4-layer model. What about the DoD model or the 5-layer model? How are these not correct? Also, 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? The conclusion was very comprehensive and well done. However the paper over was difficult to read because of the large paragraphs with no spacing to indicate different topics.

  10. tnovosel
    June 24, 2009 at 4:44 pm

    The formatting for the laboratory report for team five was somewhat hard to follow for the majority of the data was lumped underneath the methodology section. Consider putting more section heading and transition statements into the team’s reports.
    In the abstract, team five gave a definition of active reconnaissance, which they stated as” a method used by attackers to footprint a remote system by actively probing the network for information and getting results back. “The team also gave a general overview of the laboratory assignment.
    In the literature review section, team five appeared to be missing the supporting data for the articles or relate the articles to each other .The team appeared to tie the themes of the articles to red teaming and penetration testing. The team did relate the articles to the laboratory assignment. Within the literature section Team five also went into their discussion of the TCP/IP model. Team five sided with those who think the TCP/IP model should be comprised of five layers. The literature review section of team five differed from the other groups in that they described the relationship between penetration testing and SCADA devices. Team five stated” Because so many of the tools used in penetration testing and active reconnaissance operate in the network layers of the OSI model they can be applied to discovery and exploitation of SCADA networks as well. “The team went on to say that SCADA devices should be included in attack trees and test planning when conducting a penetration test.

    The methodology section gave an overview on what was to be done in the laboratory assignment and was a catch all for all of the team’s supporting data. Team five described what they planned to do in their virtualized test environment by using tools such as SolarWinds MAC Address Discovery, combined with Ping Sweeps and port scans using nmap to determine the number of hosts on a designated network, their IP addresses, and an approximation of why type they were based on the ports they had open.

    In the SCADA protocol section within the methodology section, team five described the layers of the MODBUS, DNP3, and DeviceNet SCADA protocols. The team did not describe the layers of the MODBUS+ and RP570 SCADA protocols, which were aligned later on in the laboratory report.

    In the findings section, group five somewhat described their test environment. Team five experimented with Tor for anonymity purposes, but the team concluded that the tool was proved slow and unreliable.
    In the issue section team five stated that they had problems with the BackTrack 3 VM image provided by the BackTrack team which had an older version of VMWare Tools loaded in it which prevented networking from functioning properly. However, team five did say they were able to overcome their problem via fixing an installation script.

    In the conclusion section, team five concluded that any attacker who used active reconnaissance would be better off running the attack from a compromised machine, which would somewhat solve the anonymity issues with active reconnaissance.

  11. chaveza
    June 24, 2009 at 4:53 pm

    The team’s abstract is clear and they identify everything that is they are going to discuses in this lab. They do a good starting out with the originals of red teaming and the principle behind it. Agreed, that define goals are important part when conducting projects such as penetration testing. The team talks about different methods to obscuring your location using tools such as Tor and IP reflector. Another place which the team may want to check out is http://www.covermyass.com which will similar to Tor and IP reflector. The team then goes on to talk about SCADA. Overall the team does a good job covering the reading. They go into great detail under there methodology. They mention several tools such as Solar Winds MAC Address Discovery for actively examining network surroundings. They also mention combining tools such as with the Solo Winds with Ping Sweeps and port scans. This method could be dangerous because IDS systems could recognize several packets going through the network which can raise suspensions.
    The team mentions having problems with Backtrack 3 VM image they received from remote exploits is good information to know. They had an older version of VMware tools which simply is updated using VMware workstation. Perhaps another method of getting network tools to function is using the shell to assign the interface with a static IP address. Without more information on what they had problems with this may or may not be true.
    The groups charts were very clear and well put together.

  12. June 24, 2009 at 8:53 pm

    I agree with the critiques of the SCADA section of the methodologies. After re-reading, I think a good portion of that belonged in the literature review.

    @mvanbode – The kinetic layer was intentionally left blank, it would’ve been better to fill it with “n/a” or something similar to convey this. We struggled to define what it truly meant to actively probe something that was kinetic.

    @gdekkerj – The DNS tool was included on the premise that DNS data ‘could’ be hosted on premise and subject to more stringent monitoring on the part of the target. Caching in the DNS system may limit the effectiveness of this defensive strategy and needs to be taken into account both by attacker and defender.

Leave a Reply