Abstract
In anti-forensics attackers attempt to erase or disguise the traces of their intrusion and try to make the investigator’s work as difficult as possible. Techniques used to elude computer forensics operations range from the simple deletion of log files to the installation of advanced and nearly invisible rootkits at the system level. An important work in this area is Eoghan Casey’s Association for Computing Machinery (ACM) article discussing sophisticated intrusions and examining the relationship that anti-forensic techniques have with national security concerns. His article, “Investigating sophisticated security breaches,” relates how sophisticated intruders operate, weaknesses that they use, and some methods to overcome or prevent certain anti-forensics techniques.
Lab 7 is the compilation of all our previous labs. Building upon what we have learned in our previous labs we now have the opportunity to put that knowledge to the test. Lab 7 gives us the opportunity to use the tools we’ve learned to defend against an attack from an adversary as well as try an attack against one of our adversaries. We will carefully create a plan for exploiting our assigned adversary and will report back to that team when the exploit was successful or defended against. Professor Liles will also be notified.
Literature Review
This week’s review of published literature builds upon the information presented, and knowledge gained from all of the articles and exercises from our previous 6 labs. All of the articles discussed in this literature review directly relate to what we have been learning in the previous 6 labs. The common thread tying the articles together in lab 7 discuss the prevention of security breaches and the ability to ascertain the perpetrators who exploit the systems. In addition, a couple of articles tie in nicely overall to what this course has been all about. Setting up of a lab based setting whereby we as students learn about tools used to defense against and/or use to exploit systems. All of this has been done in a safe and controlled environment. The last article presented this week relates directly to the exercise in lab 7 in which we attempt to defend against and exploit each others systems.
Network intrusions are the most challenging computer crimes to investigate, especially when the intruders are highly sophisticated and motivated (Casey, 2006, p. 49). In his article “Investigating Sophisticated Security Breaches” Eoghan Casey gives us insight into the difficulties investigators encounter when dealing with network intrusions. Acting quickly is essential to preserving evidence before it is lost or destroyed by the attacker. Sophisticated intruders gain entry to networks through known vulnerabilities and conceal their presence while obtaining valuable data using strong encryption tools to cloak their activities by encrypting data before they steal it (Casey, 2006, p. 49). Highly skilled investigative teams with specialized tools for preserving hard drives, physical memory, and network traffic are needed to catch sophisticated intruders. The ideal team for investigating an intrusion should be experts in information security, digital forensics, penetration testing, reverse engineering, programming, and behavioral profiling (Casey, 2006, p. 54). Improved training, tools, and data gathering techniques are needed to help investigators. In our previous lab exercises we have examined all of the above. This by no means makes us experts however; it does help us gain insight into just how important understanding these concepts can be for investigating network intrusions.
Mobile agent technology offers a new computing paradigm in which a program, in the form of a software agent, can suspend its execution on a host computer, transfer itself to another agent-enabled host on the network, and resume execution on the new host (Jansen & Karygiannis, 1998, p. 35). In their article “A Protocol Preventing Blackbox Tests of Mobile Agents”, Fritz Hohl and Kurt Rothermel presents us with a protocol for preventing testing attacks against blackbox protected mobile agents. There are a few problems associated with mobile agents. First, they allow programs on computers that are not controlled by the employer of the computer. Second, there is a fear of the computer owners obtaining viruses, worms, and Trojans that will ultimately damage their systems (Hohl & Rothermel, 1999). Blackbox protection can be used to prevent most malicious attacks however; there is still the threat of blackbox testing. Blackbox testing attacks can be prevented using a protocol that needs a small service, a registry, on a trusted node. The assumption though is that the participating agents have the blackbox property to protect against modification attacks (Hohl & Rothermel, 1999).
Computer security is of interest to everyone. Whether it’s your own personal computer at home or the one you use for work or school there is great concern for protecting it against viruses or malicious attacks. Courses like TECH 581-Computer Operations involving hands on lab participation allow us to understand how to protect our pc’s and networks against such attacks in a controlled and safe environment. In their article “Defense Against the Dark Arts”, Mark W. Bailey, Clark L. Coleman, and Jack W. Davidson introduce us to their method of teaching computer security. Much like our class the authors focus their course on defending against viruses and introduce their students to tools that enable them to detect and defend against attacks. Using compiler tools allows the authors to accomplish two objectives at once. While teaching their students about viruses, worms, and vulnerability software, they also present concepts of computer science by studying program analysis (Bailey, Clark, & Coleman, 2008, p. 315). The motivation for teaching their course was to make students aware that threat to computers such as viruses and worms are a serious problem, and that computer science students should understand malware schemes, how to detect them and how to defend against malicious software.
Lab based, hands on courses in computer security are an effective way to teach technology students about malware and hacking attacks. This article as well as the one prior relates to all of our lab exercises in that we were able to set up a network in an isolated controlled environment, and then using the exploit tools we researched, performed penetration testing and ultimately attacked a pre-determined team. In her article “Cyberattacks: A Lab-Based Introduction to Computer Security”, Amanda M. Holland-Minkley introduces us to the course she developed. Her course, appropriately named “Cyberattacks”, was created to teach her students about programs that are developed to defend against exploits rather that to exploit users (Holland-Minkley, 2006, p. 39). Even though her audience was designed for non-major and introductory level students it still was a good start at teaching students about computer network security. As she continues to develop her program, in time it will become more like the program and labs we have taken in TECH 581-Computer Operations.
Red team-blue team exercises take their name from their military antecedents. The idea is simple: One group of security pros, a red team attacks something and an opposing group, the blue team defends it. Originally, the exercises were used by the military to test force-readiness. In the ’90s, experts began using red team-blue team exercises to test information security systems (Mejia, 2008)
In their article “Breaking Blue: Automated Red Teaming Using Evolvable Simulations” Stephen C. Upton, Sarah K. Johnson, and Mary L. McDonald discuss an approach to manual Red Teaming called AutoRedTeaming. Red Teaming has been used for some time now in the military defense community to uncover system vulnerabilities (Upton, Johnson, & McDonald, 2004, p. 1). The authors discuss a supplemental approach to red teaming which they have begun to develop called AutoRedTeaming. This is where they automate the vulnerability discovery process using a combination of algorithms and agent-based simulations to “break blue” (Upton, Johnson, & McDonald, 2004, p. 2). The authors conducted their first tests of the AutoRedTeaming concept. The results of the test run of one of their algorithms against the test scenario found ways to “break blue” and obtain significant volumes of data (Upton, Johnson, & McDonald, 2004, p. 2).
Methods
For the first part of the lab a machine operating system was chosen. Due to the renowned security associated with Linux operating systems, the group decided to use Debian Linux. When choosing security measures for the chosen virtual machine, the group decided on using the “iptables” firewall software for Linux. The configuration file for iptables was configured as follows:
# Generated by iptables-save v1.3.6 on Tue Jul 14 14:10:20 2009
*filter
:INPUT ACCEPT [6:468]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state –state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp –dport 22 -m state –state NEW -j ACCEPT
-A INPUT -j LOG –log-level 4
-A INPUT -j DROP
COMMIT
# Completed on Tue Jul 14 14:10:20 2009
This allows only connections on port 22 for remote access. We decided to use SSH2 as the method for allowing remote logins to the machine. Remote connectivity was part of the requirement of the lab; otherwise we would not have allowed it. While SSH2 does have a vulnerability associated with it, it can only be exploited under certain circumstances. The iptables config also drops all packets that are not part of an established connection. Therefore, the machine will not reply, even with a reject packet to the source host. This reduces the effectiveness of port and ping scans. The firewall is also configured to log input drops in order to record any attacks attempts. Once the machine had been configured, the machine was left on during the specified time window and the IP address “205.215.116.50” was given to Team 5.
Once our machine had been configured, we had to plan our attack phase against Team 2. Team 2 had notified us that their IP address is 205.215.116.52. First, before an attack can be launched, one must identify the purpose of the target and the attack. The point of the lab isn’t necessarily to successfully exploit the system but rather to hide all attempts of an attack. Ideally, a successful exploit would be desired but the overall stealth of the attack is the goal. The first part of the attack is reconnaissance. What is the target operating system? Are there any open ports on the target system? The ideal method of obtaining this information is by performing a passive scan of the system. However, this method requires certain environmental characteristics, which are not present in this scenario. These characteristics will be covered in greater detail later.
The next possible method of reconnaissance is active scanning. This method allows for easier detection of the target, but increases the risk of detection of the attacker. Therefore, certain precautions must be taken into account. Nmap was used to scan the target. The command and arguments used to perform the scan were as follows: “nmap -e eth0 -T Sneaky -p1-1024 -O -sS –source_port 999 -S 205.215.116.52 -PN 205.215.116.52”. The timing for this attack was set to “Sneaky” in order to reduce the likeliness of detection; however, this timing increases the duration of the attack. In order to reduce the duration of the attack, only ports 1024 and below were scanned. The results from only these ports can give us an idea of the security measures in place, without having to scan all 65550 ports. The scan’s source port and source IP address were also spoofed in order to avoid detection. The source IP was set to 205.215.116.52, which is the IP of the target. The actual IP address of the attacking machine was 205.215.116.22. The scan was also set to perform OS detection and use SYN packets (for a quieter scan). After some time, the scan completed. The results indicated that all 1024 ports were filtered. Therefore, no exploits could be used and the attack was over, because no operating system version or any open ports could be detected.
Findings
During the attack phase, the firewall logs for iptables were checked. The logs indicated evidence of a port scan from the IP address 205.215.116.33. The /root folder was checked for the required exploit file from Team 5, but no file existed. No other evidence of attacks from any other sources existed. After the machine had been powered off once the attack window had passed. Team 5 had reported a successful exploit against the IP address 205.215.116.50. However, in their description, they indicated that the machine attacked was a Windows XP SP0 machine. Possible reasons for this could be that another machine pulled the same IP address from DHCP. Of course, these tests were all run on a subnet that contained many different attacks happening simultaneously. It is also possible that other attacks could have changed the results, such as the possibility of ARP poisoning or other attacks that could have redirected the attacks to another machine. Of course, the point of the lab is to detect the attacks, and a port scan was detected. It cannot be certain that the attacking machine was in fact Team 5. This is true due to avoidance methods such as IP spoofing and due to the fact that Team 5’s scan may have been only performed on the Windows XP SP0 machine that shared the same IP address.
The attack against Team 2 was unsuccessful because of the security measures that they put into place. It seems that Team 2 followed a similar method of securing their machine as our group. Since all of the ports on Team 2’s machine were filtered, Nmap was able to detect that the machine was dropping the packets rather than accepting or even rejecting the packets. Because of this, Nmap was unable to discover an operating system/version due to the fingerprint matching too many OS types. Even though this firewall rule set can avoid OS detection, it can still be performed; however, this environment does not allow for it. As stated earlier, passive scanning would be the ideal method of scanning this host. When performing passive scanning, the operating system can be detected because the attack is not attempting to send uninvited traffic but rather to analyze invited traffic from other hosts. The problem with this method is that there is no traffic to analyze.
When considering the security of a system, ideally one would want the highest amount of security and the highest amount of usability out of the system. Of course, in computer security, security is traded for usability and vice versa. There must be a comfortable balance between the two. Luckily for all of Teams involved in this lab, there is almost no usability out of the machines. This brings us back to why leaving SSH2 open on our machine wasn’t important. While it is an entryway into the machine, the only commonly known attacks require the SSH2 connection to be intercepted and re-negotiated to SSH1 and then have the encryption brute forced. This, of course, requires someone actually using the system. Since the machines were administered via VMware, the connections were not used. Simply due to the fact that these virtual machines do not provide functions and merely lie dormant on the network waiting for an attack attempt, the majority of possible exploits are not possible.
While there are many types of exploits that can be performed remotely and do not require the system to be generating traffic, some ports still need to be open for the attack. Therefore, even unpatched systems can still become very resilient to uninvited attacks simply by using strong firewalls. Of course, the opposite is true too. While strong firewalls are important, invited traffic can still be used to exploit a system. For instance, if an attacker can get a victim to visit a malicious web site, exploit code can be executed on the machine and bypass the firewall because the user requested the exploit code.
Even though Team 5 exploited another system, the results of the lab have not changed. When considering anti-forensics, the port scan was still detected, though it is still unknown whether the attack actually originated from Team 5. Even if the team did attack the correct machine, exploiting is almost impossible considering the circumstances. This is because every team is using a fully patched system. Considering the information that was covered in lab 6, even if the team used an aggressive scan, such as Nessus, the results would have been the same and the likeliness of detection would have been much higher. In order for a successful remote attack, the attacking team would have to exploit a new or unknown vulnerability in the operating system that allowed for full write access to the machine. These types of exploits are rare, unless of course they utilize 3rd party software. This also requires the software to be running as a service or being used by a user. The combination of the absence of services/utilization of the machine by a user and the fact that these machines are almost completely blocked off by firewalls makes the possibility of exploitation very slim. In fact, most of the systems might as well have been unplugged from the network altogether. Therefore, the lesson learned from this lab is that the usability of a system directly affects the likeliness of an exploit.
Issues
The only issue involved in the lab was the fact that another system claimed the IP address of our virtual machine. Whether the machine had pulled the address from the DHCP server itself or if another attack (such as ARP poisoning) was used is unknown. However, we feel that it ultimately did not affect the final outcome of the lab
Conclusions
While the team was not able to exploit another team’s machine, other teams were not able to exploit our machine either. The team does not believe that the purpose of the lab was to truly be able to exploit another machine, but more the ability to learn how to protect our own systems. This lab showed that by following simple guidelines a system can be secure from a good amount of exploits. The reason why so many systems are easily exploited is because not everyone secures their system properly. If everyone followed the recommended guidelines, there would be more secure systems, which makes everyone safer in the long run.
Works Cited
Bailey, M. W., Coleman, C. L., & Davidson, J. W. (2008). Defense Against the Dark Arts. SICGSE’08, 315-319.
Casey, E. (2006). Investigating sophisticated security breaches. Communications of the ACM, 49(2), 48-55.
Hohl, F., & Rothermel, K. (1999). A Protocol Preventing Blackbox Tests of Mobile Agents.
Holland-Minkley, A. M. (2006). Cyber Attacks: A Lab-Based Introduction to Computer Security. SIGITI’06, 39-45.
Jansen, W., & Karygiannis, T. (1998). NIT Special Publication 800-19 Mobile Agent Security. 35-35.
Mejia, R. (2008, April 27). Red team, blue team: How to run an effective simulation – Network World. In Network World NetworkWorld.com – Network World. Retrieved July 28, 2009, from http://www.networkworld.com/news/2008/042508-red-team-blue-team-how.html?page=1
Upton, S. C., Johnson, S. K., & McDonald, M. L. (2004). Breaking Blue: Automated Red Teaming Using Evolvable Simulations. Presented at the Genetic and Evolutionary Computation Conference 2004, 1-3.
This group’s abstract was very well written. The abstract starts off by explaining the concept of what anti-forensics is and even gives some references to articles on anti-forensics. The abstract also gives some examples of what is involved in performing anti-forensics. The last part of the abstract explains briefly what will be done in this lab by quickly explaining the tasks involved in this lab. The literature review starts off nicely. The literature review starts off by tying all the articles in this lab into this whole course. The beginning explains that the articles given in this lab are a summary of all the labs we have been through so far. They explain that each article points out the most important points in this course. In the rest of the literature review the group does a great job in transitioning from one article to another by giving situations and explanations of what will be talked about in the next article. The group tries to tie each article into some of the others and into this course. The group gives a good explanation of what each article is about and highlights the important parts of each article. The only things that are missing in these reviews is any explanation of the methodology and research of the article, errors or omissions, and what question the article is trying to answer if there is one. Next the group goes through their methodology of how they set up a target computer, how they planned to gain reconnaissance on the target computer assigned to them, and how they attacked the target computer assigned to them. I noticed two big problems with this teams target computer they set up for this lab. The first problem I saw with group one’s lab was that they used Debian Linux for their target computer. The rules that the professor gave us specifically stated “The systems being attacked must be Windows XP, Windows Vista, Ubuntu, or Fedora Core 8 or higher.” Debian was not listed in the approved operating systems. I do not know if the team got permission to use this operating system, but they should have used something else instead of Debian Linux. The second problem with the way this team set up their target computer was that the team did not use ether a NIST document or a vendor document to secure their target computer. The rule for the lab was to use only NIST documents or vendor documents to secure the systems. The team only used a third party firewall to secure the operating system. The team did set up SSH2 to allow for remote desktop connections, but nothing else was done. The group goes on by setting up a plan of attack and explaining that the object of this lab is to hide all the attempts to penetrate the target computer. The group stated that the ideal way to get information without being detected is through passive reconnaissance. They state that passive means of gathering information will not be useful in this scenario because there is no traffic from the target computer. Since the group could not use passive means of gathering information, the group turns to active reconnaissance. The group only tries one Nmap command to attempt to gather information on the target computer. This command fails to report any information so the team gives up. This team should have tried several other methods to try and gain information from the target machine. Next the group talks about what they found during and after the attacks. The only methods of monitoring the attacks against their system was through monitoring the log files on their firewall and watching the /root folder for the exploit file from Team 5. They noted that team 5 had stated that they had penetrated them, but team 5 claimed that the system they exploited was a Windows XP SP0 system. The group states that this could have been from the amount of attacks happening on the network at that time and the amount of ARP poisoning that was being done on the network. The group claims that they were unsuccessful in penetrating team 2’s computer. They say that the target computer they were trying to penetrate also had a firewall up that filtered all the ports and dropped any requests sent to it. The group states that there normally would be a way of detecting the operating system without having to actively requesting the information from the computer. This other method would be through passive scans of the traffic from the target computer, but because there was no traffic coming from the target computer, this was not an option. The group then states that in this lab because there was no need for usability for the target computers, so the target computers were secured very tightly. They also talk about how they were not concerned about opening up SSH for remote connections, because the systems were on a virtual environment and were not used. The group goes on explaining some other methods that could be used to penetrate the target computer. These other methods could not be used because they require the user of the system to be lured into situations that could bypass firewalls and other security measures. Due to the nature of this lab these methods would not be likely. The last part of this group’s results does a great explanation of how this lab shows that usability of a system directly affects the likeliness of an exploit. The only issue the group had was that another computer was using the same address as their system. The group then does a nice job in concluding this lab. They show that the purpose of this lab was not to exploit a system, but to show that if a system is properly secured then it will be protected from most exploits.
Team one begins their report for lab seven, as they have in the past, with the abstract that explains what they will be doing in lab seven. The abstract does do a good job of explaining what will be covered, but is otherwise lacking. Based on the syllabus, any abstract that is less than two paragraphs will be judged as poor scholarship on the part of the lab team. This abstract is clearly not two paragraphs. While the abstract is one long paragraph that does not make up for the lack, and it does in fact make the abstract harder to read. Team one then moves into their literature review based on the articles and papers provided to help gain a better understanding of the lab topics. The literature review does not create any cohesion among the articles presented, and is nothing more than a listing of the chosen readings with APA style citations. Team one doesn’t even make an attempt to break up their article listing with heading that explains the title of the article they are reviewing. Because there is no apparent cohesion among the articles reviewed the literature review does not present a good overview of the state of the literature. The level of scholarship in this review is very poor, and has not seemed to have improved much since day one of the course. This does not make for a very academic literature review by any means, and I’m sorry that team one was not able to overcome that flaw in their lab reports. The methods section by team on is also lacking right from the beginning. They fail to ever mention what vendor or standards organization based document they chose to secure their system with. They mention that debian was chosen due to the and I quote “renowned security associated with Linux operating systems.” This statement serves no other purpose then to possibly exclaim how well team one can use Linux. I find this statement both offensive and inaccurate. Linux actually has a track record no better, and possibly even worse than that of Windows. Because new bugs are reported for open source based software almost daily, one was released for BIND 9 today even (7/29/2009), I question the inclusion of that statement at all. The section explaining the iptables firewall rules proves that Linux is even less usable then windows systems, which would contradict team ones discussion on usability versus security. The system secured by team two was actually quite useable after the lock down, and network services were available, assuming the correct type of NMAP scan would have been run. I also find the section on spoofing the source address in NMAP invalid. Because of it, I question team one’s ability to actually manage an IP network. If the source address of NMAP scan is set to the address of the target host, how will you know what ports are actually open? The target will only communicate with itself. The conclusions provided by team one are weak. “If everyone followed the recommended guidelines, there would be more secure systems, which makes everyone safer in the long run. “ I’m glad team one understands this fairly trivial and elementary concept.
In the abstract of the laboratory report, team one gave a description of what anti-forensics is and how it relates to the laboratory assignment. Team one also emphasized that lab seven is a compilation of all of the previous labs.
In the literature review section, team one gave summaries of each of the articles but did not always relate each of the articles to the lab assignment or relate the articles to each other.
In the methodology section, team one explained why they chose Debian Linux as their system to harden. The group added iptables firewall to their Linux flavor to enhance its security. Group one took the SSH2 route for allowing remote access. Group one used an IP address of 205.215.116.50, which was given to team five. After configuring their Debian Linux virtual machine, team one turned its attention to team two’s virtual machine, which had an IP address of 205.215.116.52. Team one used nmap during the reconnaissance phase of the attack. The team set nmap for sneaky and scanned ports 1024 and below. Nmap was unable to determine what operating system team two was using because all of the ports appeared to be filtered.
In the findings section, team one described how team five had claimed that they had successfully exploited their system, but they could not find the file proclaiming a successful exploit in their root directory. Team five had also claimed that the system was running Windows XP, which clearly was not the case since the group was running Debian Linux. Team one tried to explain the phenomenon by identifying different occurrences on the network that could have resulted in team five’s claim. Team one went back to describing why the teams were unsuccessful in their attempts to exploit the target systems.
In the issues section, team one listed only one problem, someone else used the same IP address as their system, so team five attacked the wrong system.
In the conclusion, team one stated “The team does not believe that the purpose of the lab was to truly be able to exploit another machine, but more the ability to learn how to protect our own systems. “However, I must disagree for all of the previous labs had conditioned the class for seeking out vulnerabilities in target systems and exploiting them with an arsenal of tools that were discovered throughout the different labs throughout the semester. The team stated “This lab showed that by following simple guidelines a system can be secure from a good amount of exploits.’ However, team one never described what guidelines they used in hardening their Debian Linux virtual machine. Team one also stated “The reason why so many systems are easily exploited is because not everyone secures their system properly. “ However, judging by the exploits discovered in the previous labs, it is not how the system is configured but how the system is used by the users and what applications are being run by the system.
The abstract is a bit confusing, it appears that the lit review is started in between the information that does belong in the abstract. The literature review from group one is probably their best to date. Still each paper is treated in its own paragraph with little cohesion between the sources and little mention of the literature’s ties to the lab activities. The review starts out with identifying a common thread throughout the literature provided and tying the literature back to previous labs. The first paper mentioned was E. Casey’s “Investigating Sophisticated Security Breaches.” While the previous paragraph identified a common theme of prevention and investigation of security breaches, this section was more of a summary of the paper than a discussion on how the content relates to the theme of the lab. The second paper mentioned regarding mobile blackbox testing also suffered from the same lack of application to the lab activities. The third paper, “Defense Against the Dark Arts,” begins with an odd, general statement that “…security is of interest to everyone.” This makes this section seem as if it’s the beginning of another literature review or possibly written by another author and just pasted in to the larger lit review. Either way, the section makes mention of the course as a whole but gets the course number and course title wrong.
The methodology for team one makes no mention of the NIST or vendor guidelines used to secure the system. Instead the team makes sweeping statements regarding the “renowned security associated with Linux operating systems.” The team mentions good principles of approaching the attack from an anti-forensic principle prior to any actual work being done. My biggest issue with the methodologies was the method with which the target system was scanned. The group used nmap and set the “-S” flag on the scan to set a source IP of the scan packets. If the source IP of the packets is changed, how do you expect to get any back? This error makes any scanning results suspect and invalidates the assessment that the target machine had no ports open. I found a good example of IP obfuscation with nmap using decoys at http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=10640&mode=thread&order=0&thold=0.
The findings indicated the issues that my team, team five, had with exploiting the wrong machine. I’m not sure I agree with the reasoning of another machine pulling the same IP address from DHCP unless this host pulled the .50 address and then was set to that IP manually, DHCP wouldn’t allow this. The conclusion that the attack against team two was unsuccessful because of the security measures they employed is invalid due to the reasons I mentioned above regarding the methodologies. I also take issue with the assessment that there was “no usability out of the machines.” If usability isn’t a concern, we may as well just unplug the machines.
There are a number of positive points with regard to team one’s lab write up. The literature review is nicely done, with reference to application of the information in the articles within the scope of the course. The use of a Linux based machine set this group out from the rest of the teams, and shows a degree of innovation. The considerations with respect to remote login and SSH version two show that some research was done with regard to security issues.
However, fundamental problems exist with this team’s write-up, mostly with regard to methodology. Foremost, no security document used in “hardening” the team’s defenses was ever mentioned. While this may indicate that the team felt no additional measures were required to harden the base Linux machine used, it also might simply betray a lack of research. This probably should have been an issue specifically discussed in the report. Furthermore, the ‘Debian’ variant of the Linux distribution used by the team is not specifically mentioned in the lab instructions as being allowed in the exercise. While it is true that an ‘Ubuntu’ variant is allowed, and that ‘Ubuntu’ is based on the ‘Debian’ distribution, this seems to technically violate the exercise rules, and also should have been discussed and defended in the team’s report.
Furthermore, the execution of the attack against this teams designated target appeared to be less than enthusiastically pursued. How is it that this team never checked for open ports above 1024 in their scans? This appears more as a lack of effort rather than an attempt at stealth. Additionally, if no login in means was detected by this team on the opponent’s machine, why wasn’t this issue pursued further, either by ‘rules violation’ complaints or a greater degree of target probing? This lack of thoroughness appears to indicate that this team put very little effort into actually exploiting their opponent. It should be apparent that the ‘stealth’ aspect of the exercise is more directly applicable to the events ‘after’ an actual intrusion has occurred on the target machine: after all, the team being attacked already knows that a threat exists on the network. If this team, as mentioned, was using spoofed addresses to perform scans, why would they hold back from more intensive interrogation of ports? The defending team would be hard pressed to prove that they were being attacked by a specific opponent, with the worst consequence being an hour lost in offensive activities, after which two hours of target exposure would be guaranteed. It is apparent that team one gave very little thought to an offensive strategy this exercise.
Finally, the circumstances of team one’s machine being replaced by another during the scope of the exercise is ‘highly’ suspicious. My team, aware that IP addresses were being assigned by DHCP, periodically checked to insure that our machine was indeed accessible to our opponents at the advertised IP address. That team one did not notice this change, or mis-configured their machine could indicate incompetence: although I do not think the members of team one incompetent. I suspect team one may know a bit more about the incident than what they revealed. What is the probability of team one’s machine being replaced by a machine running Windows XP with no service packs installed? What fortunate set of circumstances led to this machine assuming team one’s IP address in the middle of an obvious attack? No, it seems much more likely that all the traffic to team one’s machine was being intentionally diverted to this honey pot. Third parties could have been involved in this misdirection, but the question is: who? Teams five and two seem out of the question, and I can vouch for the active members of team three that we did not aid team one. Team four may have collaborated with team one in this regard; however, this seems unlikely, but if true would hint at active participation by team one. I believe at the very least, team one should show a bit more curiosity as to how this occurred, if they were not directly involved. To wave one’s hands and blame it on mysterious “ARP poisoning,” and then to assert that “…it ultimately did not affect the final outcome of the lab” borders on outrageous.
Team 1 began their abstract with a discussion about anti forensics and the attackers attempt to erase or disguise the traces of their intrusion and to make an investigators work difficult. They then go onto discuss what is going to occur within the lab. Next they provide the literature review and an overall theme for not only lab seven but they tie in all the labs. The team and a nice review that discussed the subjects of the literature this week rather then telling the readers of the lab what happened in each paper. This allows for further though and was a good change for the last lab. The team then goes into the methodology section. Within the section they provided what was done to harden their system. Then they stated what the plan of attack against team 2 was. In the findings section they provided all the results from their attempts against the targeted system. Within this section they also state that they where unsuccessful in penetrating the system. Knowing this does it still mean that a windows system is unsecure. Or is it just what is done with an operating system that makes it unsecure? The team then goes onto discuss their issues and conclude that lab. The conclusion was a week part of the lab and could have had a little more provided, but overall the team did a good job.
Team 1 begins with an abstract introducing the concepts of Lab 7. They state that it is a compiliation of all of the previous labs. And, that lab 7 gives them the opportunity to use the tools that they’ve learned to both attack an adversaries system and defend their own.
In Team 1’s literature review they relate the articles assigned to this lab by stating that they all pertain to protecting a system from exploit and conducting a forensic analysis of exploits that have occurred. They also state that two of the articles are applicable to the overall concept of this course. The first article they reviewed is “Investigating Sophisticated Security Breaches” (Casey, 2006). They give a description of the article that gives us insight into intrusion detection. They relate it to the various labs they have done up until this point. They include the article “A Protocol Preventing Blackbox Tests of Mobile Agents” (Jansen & Karygiannis, 1998). They describe the article as presenting a protocol for preventing testing attacks against blackbox protected mobile agents. They provide a good description of the article but don’t include an assessment of how it relates to our current lab assignment. The next article that they review is “Defense Against the Dark Arts” (Bailey, Clark, & Coleman, 2008). The article describes a method for teaching computer security. They relate the article to this course by stating that it teaches how to detect and defend against attacks. Similarly, “Cyberattacks: A Lab-Based Introduction to Computer Security” (Holland-Minkley, 2006) describes a class that teaches students how to defend against exploits.
In the methodology section, Team 1 describes the system that they designed to be attacked and the methods that they used attack their target computer. Team 1 begins their methodology section by describing the system that they chose for the Lab 7 read teaming exercise, Debian Linux. They secured their system with the Iptables firewall and only allowed access to port 22 for remote access. They describe several options for achieving their objectives of breaching their target system. They used Nmap to conduct a slow port scan of the first 1024 ports of their target computer. They also spoofed their source IP address and port. These scan options were set to hide their scan attempts. The result of the scan indicated that all ports were filtered. Because of this they felt that no further attack could be possible. They explain their inability to breach Team 2’s system as due to the security methods that Team 2 had in place in their system.
Although Team 3 claimed to have breached Team 1’s target system, they described the system as being a Windows XP SP0 machine, rather than the Debian Linux system that Team 1 actually had. Team 1 provided a good explanation for this phenomenon as being possibly due to ARP poisoning within the laboratory environment. Team 1 included a discussion on the tradeoff between security and usability. Since the teams were using fully patched systems with no applications running, no user interaction and firewalls in place, the systems were extremely secure. I agree with Team 1 that the security of the system is affected by the usability of the system.
Group one presents a complete lab marred by omissions and contradictions.
The Abstract is odd. Why do you start talking about Casey’s article? Wasn’t there an actual point to the lab beyond attack and defense?
The introduction to the team’s literature review claims that the common tie in the articles is that they are all about exploiting systems or being able to detect the exploiters. I don’t think that’s completely accurate. The group makes an attempt to link the articles to the lab, but does so in very superficial ways. There is a total absence of any evaluative material what so ever. The group summarizes the articles, but missed key points. What is the “mobile agent that Hohl and Rothermel were talking about? What was their solution, really? Bailey et al state clearly in their paper what their motivation was, and it had little to do with the serious problem of viruses. Also, it was Bailey, Coleman & Davidson, not Bailey, Clark and Coleman. Holland-Minkley was targeting non-major undergraduate students with her curriculum. Do you really think she will push it to this level? How does what Upton et al do compare to what we’ve done?
The methods section is detailed and complete. Is Linux really known for security any more than the other options? Can you back that academically? The group documents what it did to provide security well. What Document did you use as a basis? The group’s attack method is also well documented. Why did you only scan the lower ports? Couldn’t team 2 have configured something exploitable with a higher port number? I like that you point out the real point of the attack phase. Where is that in the rest of the report? Maybe you should have had more discussion before you all wrote your separate pieces.
The findings section contains the group’s forensic methods. Why isn’t this in the methods section? The findings section is otherwise detailed and well written.
The conclusion states that the lab was about protecting systems, but earlier the group states the lab is about anti-forensics, (which is the title, by the way,) which is it? Also you say that if everyone followed guidelines their systems would be safe. What guidelines did you follow? If this is true, why the discussion of usability versus security earlier? It’s contradictory.
For lab seven, team one decided to use the Linux distribution, Debian as there virtual machine to be exploited, which was the only team to use a Linux OS. They picked this operating system because of the renowned security that is associated with Linux operating systems. The team protected themselves by the use of a firewall type software called iptables. Part of the team’s security was to have iptables drop all packets that was not part of an established connection. This being that the machine would not respond with a single reject packet from any node. An example would be if a node where to ping the ip address the node would receive a request time out error and for most users this means nothing is there.
Team one also given the opportunity to exploit team two. They had a great approach, they first asked themselves questions such as, what is the target OS? Is there any open ports? To answer these questions the team used nmap to scan the host. The team set nmap option “Sneaky” to help avoid detection. In turn using that option will slow nmap’s scan to avoid possible detection. Team one only scanned ports 1024 and below. After the scan the team discovered that all 1024 ports were filtered and no operating system could be identified. This team reported unsuccessful in there quest.