TECH 581 W Computer Network Operations: Laboratory 7, Team 3

Abstract

The purpose of this exercise is to emulate a realistic attack/defense scenario in a virtual test environment, and to use forensics to determine the pattern of an attack. First, relevant literature is consulted and reviewed. Next, the team develops a plan for defense of a virtual machine, and implements the machine according to this plan. Closely related, a plan of attack is evolved through reconnaissance and research, with an attempt being made across a network to penetrate a machine defended by another team. Finally, an analysis is made of attacks on the team’s own machine, and the results reported.

Introduction

It is an oft repeated phrase: “the best defense is a good offense.” While this may seem counter-intuitive with respect to this lab exercise, as the target for attack is a different team than the invading team, there is merit in the concept. From the initial planning stages, our team realized that a proposed offensive approach must necessarily be addressed in the defensive posture: there was every reason to anticipate the same methods might be employed against us directly. It was found, that from the very beginning of the planning phases, a large benefit was derived by creating a unified plan, which was not strictly delineated into areas of defense and attack.

It is with this noted that we set our research goals. First, we propose to develop a connected plan of defense and offense, each aspect leveraging against the other. Second, we attempt to utilize this unified plan to engage in an effective defense of a virtual machine against attacks from a network based threat (namely, team two), all the while propagating a pointed attack across the network of our own against a remote target (specifically, team four). Finally, we analyze the effectiveness of our defense using forensic methods.

Literature Review

This week’s assigned readings follow the pattern of the previous weeks, relating directly to the current lab, aspects of penetration testing, or class structure. The group read an overview of forensics in sophisticated “high stakes” security breaches, two different methods of approaching security education, a proposed methodology for automated red teaming, and software design concept for defense against “blackbox testing.”

While the majority of this week’s activity dealt with attacking other teams’ systems, the real intent of the lab experiment was to expose the students to anti-forensics, the art of hiding one’s tracks. In order to be proficient with this skill, one must understand the principles of forensics. Eoghan Casey’s article “Investigating Sophisticated Security Breaches” gives the reader an overview of best practices in digital forensics as well as a brief look at some of the techniques used to obfuscate attacks (Casey, 2006, p. 48). Casey cites the growing sophistication and organization of operators attacking networks and their ability to conceal attacks as motivation to be more serious about computer crime (pp. 48-49). He postulates that the best way to conflict these breaches is to combine the skills of digital investigator and security professional in order to efficiently and legally gather evidence once a security breach has been detected (p. 49). Casey does a good job of covering the more common techniques used to cover one’s tracks in an attack, as well as providing evidence gathering techniques and tools. He also points out areas where investigators must be cautious, lest they provide false evidence, or end up in violation of computer crime laws themselves (p. 53).

Casey’s article is well written and gives a good overview of his topic for his target audience. He implies, rightly so, that a security breech is inevitable, and that good forensics practice may help locate the parties who carried out the attack. While it is mentioned, Casey does not emphasize the idea that these sophisticated attackers may hide behind several layers of communication, and that an investigation may only detect the point of entry to the network, not the actual root attacker. Casey also avoids any discussion of preventative measures, though this is likely due to the focus of the article rather than an unintentional omission.

While Casey provides us with post-attack evidence gathering methods, Fritz Hohl and Kurt Rothermel (1999) propose a method for preventing penetration of the system from occurring in the first place. In “A Protocol Preventing Blackbox Tests of Mobile Agents”, they propose a method of validating input to web applications to prevent the use of random input generation as a scheme for vulnerability detection (p. 1). The authors see this method of probing as a major vulnerability in current application design (p. 2). They propose the addition of a registration value to application code to track instances of interaction and require that inputs from each agent to remain the same (p. 5). The idea is to prevent multiple inputs in rapid succession that would be indicative of a blackbox probing attempt.

Hohl and Rothermel (1999) propose an innovative method for preventing this particular type of attack. Even they admit that there is work to be done. The additional code creates quite a bit of overhead in the application (p. 11). The method requires manual editing of existing code and does not provide a stand-alone mechanism for validation (p. 12). The authors unintentionally provide the students with an excellent example of applying blackbox testing principles, normally used in application testing, to penetration testing. This methodology would be useful for attacking systems that serve a web based or remotely available application.

In a similar vein, Stephen Upton, Sarah Johnson, and Mary McDonald (2004) presented “Breaking Blue: Automated Teaming using Evolvable Simulations.” Rather than focus on one type of attack in the IT world, Upton et al. examine the concept of red teaming in general (p.1). The authors state that red teaming is “manually intensive” and requires the work of dedicated experts. They hypothesize that automated, simulation based red teaming could be used to gather information that could assist with the manual process and reduce “surprise” (p. 1).

The group was unable to find the actual presentation that the document summarizes, so it is unfair to criticize the brevity or quality of the work. It is notable that the authors establish the idea of automated testing, in this case for what appears to be military or law enforcement tactical simulations. Even in this early stage, they find that simple simulations only produce the results of preset input, and postulate that artificial intelligence or learning systems are needed in order to fully realize the potential of automation (Upton et al., 2004, p. 2). Based on the results of the assignments in this class, it is possible to extend the ideas that Upton et al present to build a red teaming or penetration testing engine that would be very capable in aiding system testing.

In order to use such a tool however, the operator would have to first understand the basic concepts of security. “Cyberattacks: A Lab-Based Introduction to Computer Security” by Amanda M. Holland-Minkley (2006) describes a course dedicated to teaching these basic concepts (p. 39). Holland-Minkley states that there is a growing need for information security education and while it is crucial for information technology students, those in other majors should be taught as well.  She proposes a course designed to this need (p. 39). The author proposes curriculum that teaches both the theoretical side of the topic, such as ethics, history, and policy, and the applied view, with labs that demonstrate malware, viruses and other exploits, with the goal that students become more aware of the potential dangers and be capable of taking steps to mitigate the threat (p. 39).

Holland-Minkley (2006) declares the program to be a success. While her methods appear to be sound, her statistics show little or no positive change, and in some cases, what the group feels is actually a step backward (p. 44). In spite of this, the author presents a solid program of study for undergraduates in non-technical majors who wish to increase their knowledge of the topic. While most of the skills are transferable, the content appears to be a bit elementary for graduate students in technology majors.

Another spin on teaching information security technology comes from Mark W. Bailey, Clark C. Coleman, and Jack W Davidson (2008) in their drolly named “Defense Against the Dark Arts.” The authors state that rapidly declining enrollment in computer science classes is a major issue. They propose to combat this loss of enrollment (and presumably therefore billable hours) by creating a class that “today’s student considers relevant.” To this end, they propose a class that teaches programming by focusing on malicious and “anti-virus” code (p. 315). The rest of the paper is a detailed description of the curriculum. There is nominally a section on ethics in the first week of the class. The rest of the content teaches engineering and reverse engineering of code using viruses and other exploits as examples (p. 316).

Bailey et al. (2008) call the class a success, and in that it appears to have met the goal of increased enrollment in computer science courses, the team has to agree (p. 318). While the class the authors describe is similar to the one we are taking now in that it teaches controversial and potentially dangerous skills, the team finds the authors’ motivation suspect. If the goal was to prepare well trained developers in methods to combat poor code writing practices and malicious software, we would have no problem with it. However, Bailey et al. blatantly state that the primary concern was drawing in students, which translates to watching the bottom line (p. 315). Using “edgy” dangerous material for financial gain smacks of unethical behavior.

Methodology and Procedure

Plan of Defense

Foremost, the team decided to use a Windows XP Service Pack Three machine, as prior research had shown this to be a secure setup. Additionally, it was believed that though a Linux machine could be properly configured for the exercise, by large majority the team members were more proficient and comfortable in a Microsoft NT kernel based environment. It was also felt that extensive forensics, if necessary, would be easier to accomplish for the aforementioned reasons. In order to secure this system, the Microsoft Specialized Security, Limited Functionality (SSLF) Workstation group policy for XP SP3 as per “Security Compliance Management Toolkit: Windows XP” was applied (document from Lab five). Also, the firewall was enabled, with only a single port for Secure Shell (SSH) being opened. As no files were being shared, the Microsoft file sharing service was disabled for the outward facing network interface. Finally, all existing user accounts were disabled, including the default “Administrator”; with two accounts being added, one with administrative privileges and one without, both with high complexity passwords to prevent brute-force cracking attempts. Two network interfaces were configured; one which connected to the “outside” laboratory network, and another which was only accessible by local subnet.

In order to facilitate the network login requirement functionality of the exercise, the team installed the OpenSSH server for Windows package (http://sshwindows.sourceforge.net/).  One other SSH package was evaluated (http://www.freesshd.com/ ) , but it was found to be prone to crashes and did not appear to interface properly with the native Windows NT authentication system. The OpenSSH server was installed, the proper commands were run (mkgroup, mkpasswd) to generate a permissions mapping for a non-administrative user, and the service was started. The non-standard high port number of 22000 was chosen for the service to listen on; while this does very little to deter detection, it might not be apparent on a quick Nmap scan, which typically interrogates only the low one thousand ports.

The team elected to use this SSH server for two specific reasons. The first, as the graphical user interface was not present, many local escalation exploits were unlikely to function; i.e. Internet Explorer could not be run from the command line, and other Graphic Device Interface (GDI) elements could not be compromised. Secondly, as the main remote connection means of Microsoft Windows (Terminal Services a.k.a Remote Desktop) is unable to verify the identity of the remote host on connection (unlike SSH which uses a fingerprinting system), well known “man in the middle” attacks exist by which to exploit this flaw. The team believed the installation of this SSH server application to be within the bounds of the exercise, as Microsoft documentation directly recommends the use of the OpenSSH server for use with its Windows Services for UNIX  (SFU) since it provides no SSH functionality natively (Russel, 2004). We did not consider this being “artificially protected” as it is a standard usage pattern; moreover, no complaints were raised by the attacking team in this regard.

In regards to other security measures, after discussion and reconnaissance of other teams’ shared network folders, it was decided to run the VM for the exercise from the temporary disk storage allocated to the Citrix session, as this appeared completely unavailable to other users.  After further consideration, it was thought that a dropped Citrix session might cause the entire VM to be erased, and so it was copied to the presumably private “Students” U: network drive. The passwords on this working copy were changed, and the original VM labeled “Lab 7” was left in the shared folder, with fake run lock folders added in an attempt at misdirection.  This was done to obscure the actual identity of the target machine, and to throw off any attack which involved circumventing file permissions and “stealing” the VM’s drive for password file cracking purposes.

The team was forced to modify its defense policy, as on the second day of the exercise, attackers (team two) successfully logged on to the team’s machine. Evidence of intrusion was gathered, and permission for an hour of off-line time was obtained. It was believed that the laboratory instructions indicated modification to the team’s machine was allowed during the “down time,” and so the account passwords were changed. This action was later disputed by the attacking team as “cheating,” although it was ultimately judged by the highest authority to be a reasonable interpretation of the rules, if not the original intent, and so was allowed to stand without remedial action.

Because of the nature of this intrusion, it was suspected that one or more team resources were compromised. A new login password was emailed to the contest judge in an encrypted zip folder, with previously known private shared information used for the decryption pass phrase. Additionally, the new account passwords were not emailed to other team members, but held only by the person maintaining the team’s VM. The SSH client side software was changed to reject connections which did not use SSH version two: the reason for this will be examined further in the forensic analysis section. Finally, the Citrix environment was treated as compromised, and so no logon procedures were initiated into the team’s VM for the rest of the exercise. These defensive steps ultimately proved successful, as no other attempts were made to enter the team’s machine.

Plan of Attack

Before the red teaming exercise began we started passive reconnaissance by inspecting the previous laboratory reports that had been submitted by team four to Professor Liles’ blog. We used this to determine possible information leakage of operating system type, passwords and security methods used in previous labs. Laboratory five required each team to choose an “as-is” operating system and attempt to exploit it. Then, the teams were required to select a security document that pertains to the operating system that they chose. For lab five, team four chose the Windows XP SP3 operating system and NIST document SP 800-68 to secure it. We believed that it would be unlikely that team four would put in the extra time and effort required to select a different operating system and vendor documentation for lab seven. We also located the user name and password that they had assigned to their systems in lab one. Although we felt that it is unlikely that they would use the same user name and password, it was worth noting.

Once the red teaming exercise began we started conducting scans for open ports on the target system using both Nessus and Nmap. To avoid detection we conducted the scans late at night when it was unlikely to be monitored. Scans conducted on team four’s system late Wednesday night and Thursday showed that there were not any open ports. Since this was our only avenue of attack at the application layer, we began exploring other options for compromising the target.

One of our ideas for compromising the system involved making a copy of team four’s virtual disk file. The virtual disk file could be browsed using VMware Workstation so that the SAM file could be extracted. Once that was done, a password cracking tools such as Ophcrack, John the Ripper, or Cain and Abel could be used to brute force the password from the SAM file. Using the recovered user name and password, the virtual machine could be booted with VMware Workstation and any other information necessary to breach their system could be obtained. This method proved untenable since the folder permissions did not allow us to copy the virtual disk file from team four’s folder.

We also investigated vulnerabilities within VMware itself.  We were able to find a few reported vulnerabilities associated with VMware, however only one that would possibly assist us. The others were simply denial of service attacks (CVE-2009-1146, CVE-2008-3761)  (“VMware Products”, 2009). The path traversal vulnerability within VMware could allow a user within the virtual machine to have unauthorized access to the host file system (CVE-2009-1147)  (“VMware Workstation”, 2007). By creating a shared folder with the host operating system, a user within the VM could create a specially constructed path name to gain access to the host folders. This could be used to access the virtual disk file of our target (Jackson, 2008). Unfortunately, this method of privilege escalation did not work when running Windows XP in the virtual environment.  We attempted to mount the shared folder using nUbuntu, however it deadlocked VMware during two consecutive attempts.

A network scan of the target system on Friday showed that the results of the scan had changed from “no open ports” on Thursday to “all ports are filtered” on Friday. The change in scan results indicated that Team four might have activated a firewall sometime between the scan on Thursday and the scan on Friday. We were hopeful that team four would also activate their remote login as required by the lab specifications.  Before accusing team four of not following the laboratory instructions, we needed to be certain that a scan would not reveal the open port; that it was not somehow hidden by Windows firewall.  According to Microsoft documentation, Windows firewall uses a stateful packet filtering system. When a network request is made from the system to a remote computer, a port is opened to allow for a response. Windows firewall monitors these requests and only accepts packets on that port whose source IP address matches the destination IP address in the initial request. This keeps unsolicited packets from entering through that port. To allow for outside connections, however, it’s necessary to create an exception within the firewall. This allows a single port to be opened to requests from outside traffic. Windows firewall allows for the exception of a port and source IP address, but not protocol (Davies, 2005). We tested this hypothesis by configuring Windows firewall in a Windows XP SP3 with a configured exception.  We ran a port scan to insure that the open port was visible when a specific IP address had not been included in the exception. Since the instructor had not publicly furnished an IP address, we believed that either no exception had been made or no remote log in service had been configured.

We emailed Professor Liles and team four to verify that team four did, in fact, provide a remote log in. Professor Liles confirmed that they had not.   He emailed back a short time later advising that team four had sent him login information at that time, however, he was unable to log in. We verified through a port scan that team four still did not have any listening ports on their virtual machine. Another scan a short time later revealed that they had a listening port at number 3389 (ms-terminal services).  A simple Google search showed that port 3389 was the default port for Windows Remote Desktop. A quick login attempt from a Windows XP VM on the network confirmed this.

Our initial login attempt to team four’s remote desktop was made using the user name “administrator” and the password” Pa88word”, which team four had provided in their lab one write-up.  We were unable to log in using these credentials. We began researching known vulnerabilities associated with Remote Desktop. Two vulnerabilities were found; the first involved using a buffer overrun to create a denial of service attack (“Microsoft Security Bulletin”, 2005). A denial of service attack would not offer us any benefit since our objective was to breach the system. The second concerned possible information leakage (“Microsoft Security Bulletin”, 2002). Both of these vulnerabilities were quite old and likely already patched. We decided to attempt to capture the user name and password during a login using the security tool Cain and a man-in-the-middle attack. We did this by performing ARP poisoning of our target MAC address while listening for a login attempt.

We also began researching tools to brute force the remote desktop login. Hydra appeared to be the most promising. Hydra uses tables of possible login credentials and works with many different remote login protocols. A closer look however, showed that it did not work with Remote Desktop. In fact, searches for online password crackers that work on Remote Desktop revealed nothing useful. Since Remote Desktop uses the same protocol as Terminal Services, we searched for tools to brute force a terminal services login. Two programs looked promising, TSCrack and TSGrinder (Gates, 2009). Only one site could be found to download TScrack. The attempted installation crashed the VM, making it unbootable. Once we copied a new VM and reconfigured it, we turned our focus toward TSGrinder. After installing TSGrinder we attempted to run it against our target system. On numerous attempts to use TSGrinder against the remote system, it reported that it could not get a handle to the remote login page.

We continued our attempt to capture remote desktop login using Cain with ARP poisoning, however at this point we believed that we had exhausted all other feasible options. There were some options that we believe would have worked, but would have been unethical. For example, we could have captured Citrix login information of Team four members using Cain. Once we cracked the password hashes, we could have logged into Citrix with their credentials and had access to their target VM virtual disk. As proof of concept, we captured the NT hashes of two of our own team members. We were able to brute force the passwords within about five minutes each. We also considered brute forcing their student email to capture communication between the team members and instructor.   Another option involved crafting a spoofed email that appeared to be from Professor Liles. The email could direct them to visit a malicious web site from their target system, or simply advise them to login using remote desktop (so that we could capture their login credentials).  This too would have fallen outside the scope of acceptable behavior.

Forensic Investigation

While the team’s VM was not compromised according to the rules of the exercise (no files were placed on C:), it was felt a forensic investigation of the unexpected password compromise to be important, both from a defensive standpoint, and as a fulfillment of the laboratory exercise. This proved to be somewhat challenging, as the compromised elements seemed to lie outside our domain of control, and so only best guesses could be made.

The initial intrusion was noticed by a number of things present in the team’s VM. Repeated login actions, both successful and unsuccessful were found in the log files. Additionally, a number of zombie processes were noted, including “notepad.exe,” which most likely resulted from starting this application from a command line with no graphical user interface present (the team was able to replicate this scenario exactly by this method, and so assumes this is what occurred). Most telling, however, was a text file named “team2.txt” left on the non-privileged user’s desktop. The team was unsure if this was actually an attempt by team two or a test by Professor Liles, as the blatant lack of stealth did not seem in accord with the laboratory goals for an attacking team. All these are illustrated by Figure 1, which was submitted as evidence toward the team’s previously mentioned “down time” request. In actuality, uncertainty existed even at this point that team two was involved, and it was fully expected that Professor Liles would reply that this had been a test for rules conformance. When the request for offline time was granted, it became more certain that this was the work of team two; ultimately confirmed by the “cheating” complaint of the next day.

It was after this incident that the team increased its level of network reconnaissance. Extensive examination of the network was done, and it became obvious that massive ARP poisoning, likely by multiple parties, was taking place. A simple “arp -a” executed from the Windows console shown at different times during the exercise illustrates the changing MAC addresses (Figure 2) . A series of “nslookup” commands recorded at this time revealed the machines from which traffic was being redirected (if DNS could even be trusted at this point):

M:Program FilesSupport Tools>nslookup 205.215.116.9
Server:  dc01-cit.cit.puc.purduecal.edu
Address:  205.215.116.7
Name:    sql01-cit.cit.puc.purduecal.edu
Address:  205.215.116.9
M:Program FilesSupport Tools>nslookup 205.215.116.10
Server:  dc01-cit.cit.puc.purduecal.edu
Address:  205.215.116.7
Name:    web01-cit.cit.puc.purduecal.edu
Address:  205.215.116.10
M:Program FilesSupport Tools>nslookup 205.215.116.2
Server:  dc01-cit.cit.puc.purduecal.edu
Address:  205.215.116.7
Name:    citrix01-cit.cit.puc.purduecal.edu
Address:  205.215.116.2

Additionally, Wireshark was used to analyze ARP traffic, and IP conflicts were reported.

While we were uncertain as to the exact function of the machines which were compromised on the network, we assumed by the host names that one was a web portal, another possibly the Citrix application server, and the third to be an authentication or session database of some sort. We inferred this using web searches on Citrix based deployments, with the sites found being typically represented by one such as this:  http://www.petri.co.il/record-audit-terminal-citrix-rdp-sessions-observeit-product-overview.htm . The member of the team doing this research was relatively unfamiliar with Citrix deployments, and cannot be certain the assumptions made were accurate. Although not noticeable in this specific instance, it was realized that the file server for network shares appeared to be compromised by traffic redirection also.

It is with these details in mind that the team became extremely paranoid about all data which in theory could cross the poisoned network. It was at first assumed that the SSH login connection had been compromised, as research from an offensive angle revealed that such programs as “Ettercap” and “Cain and Abel” were capable of  man in the middle attacks on SSH connections by requesting a SSH protocol lower than two: previous protocol versions are susceptible to this type of attack. It was noted that “PuTTY,” the client side program used, by default will downgrade from connection protocol version two if requested by the party being connected to. The “PutTTY” settings were modified in order to eliminate this “downgrade” vulnerability; and the assumption was made that this was the means by which team two acquired the login name and password. However, an analysis of connection logs to the team’s VM via SSH revealed that no connection was ever made to the machine over the “outside” network using the compromised password up to the point that the break-in occurred. Hence no interception could have occurred up to the time of this event.

Further in this line of inquiry, the login records appeared to indicate by both behavior and IP address that the same party which initiated the very first login of the attack also planted the file on the desktop (although this cannot be known for certain simply by IP address, as this can be spoofed). By behavior, we note the first hour of login attempts unsuccessfully employed the login name  non_root  when the actual real login was not_root . We think it likely that this was due to the attacking team misreading a capture file or errors induced by the verbal transmission of information. It also might indicated this was transcribed from short term memory, such as with over-the-shoulder peeking. There was a reverse IP lookup anomaly noted by the SSH server in the logs during this attack period, but this occurred ‘after’ the first successful login by the aforementioned attacking address: so this indicates that interception of a session, if it occurred at this anomaly point, was the ‘not’ the root cause of compromise. It became apparent that the probability of this being the compromising means was rather low.

A possible means of compromise was considered in the use of email based communication. It was unknown if university email was capable of being intercepted; although precautions by means of encryption were taken on this paranoid notion. A more likely scenario is the use of sniffed and cracked network credentials to directly access the relevant email accounts (which in this case have the same login usernames and passwords), although we did not believe team two would utilize this questionable technique. Therefore, we ruled this as a low probability source of compromise also.

Further, the method of using sniffed credentials to access the team’s account file shares, and copying the running VM’s main virtual disk was examined. The team verified that it is possible to copy the virtual disk while the VM is running (this was tried successfully in a experiment) Also, it was certain that some of the team members’ credential’s were available: the usernames were advertised, and the login passwords used were the default assignments, which were of a well known format and were very weak (the hashes were cracked in about five minutes, as noted in the attack plan section). However, as the infamous LanManager hash vulnerability was eliminated by security policy, a brute force approach was presumably the only viable method to attack the team’s VM configuration (Gilman, 2004) . Since the compromised password was  con2->sys6=TRUE;  it is nearly certain that this was not cracked due to its complexity and the short time span of the exercise; and so this was ruled a very low probability of being the means of compromise.

Finally, we investigated the possibility of the Citrix session being compromised directly, and thought this the most likely. It appeared in Wireshark that all the traffic for the session was arriving in plain text to the connected client over the compromised network: therefore, we think it likely the team’s VM’s user account name and password were “sniffed” off of the network using Ettercap or equivalent. Essentially, we believe all keyboard input was being transmitted overtly on the network, and so judge this the most likely means of compromise. It is also possible that the Citrix session was accessed directly using specific session usernames and cracked password hashes, but we feel the less ethically questionable means most probable when coupled with its simplicity.

Results and Discussion

Simply put, the team (team three) was unsuccessful in its attempts to compromise team four’s virtual machine. In the area of defense, we were ultimately successful against team two’s intrusions, although team two did enter our system via remote login. The forensic analysis of this intrusion showed that the user name and password utilized was in all likelihood obtained by monitoring of the team three’s Citrix sessions.

This lab has verified what we have seen in previous labs: most system vulnerabilities occur at the application or human interaction layer. Attempting to access a system without any network-facing applications and with no user interaction occurring on the system is analogous to laying siege at the walls of an empty city.  Even lower level reconnaissance such as packet sniffing and ARP spoofing require some network traffic from a user or application to be effective. A properly configured operating system is secure when left to itself.

With relation to this exercise, the team must admit that with the benefit of hindsight, we would change a number of things with regard to methods and preparation. There can be no doubt that it was a mistake on this team’s part not to map the network which served as the “battlefield” well before the action began. As we did not know what the “normal” network should look like, we found it difficult to ascertain when something was amiss. We could not trust IP addresses, DNS queries, or MAC addresses, much less services which were network based. A bit of reconnaissance and research before the exercise began would have put us in a much better position defensively, including the option to use static ARP tables for key network servers. On the offensive aspect, the team probably should have begun ARP poisoned traffic interception from the start of the exercise. However, as unstable as the network appeared during the exercise when this team was not ARP poisoning, it may have proved to be ultimately infeasible due to the increased amount of network disruption.

Further considerations expose the risk of using a direct Citrix session to manage the defensive aspects of the team’s VM. Although it is not known if it would technically violate the rules of the exercise, we would consider using a VPN connection to the lab network, with an additional tunneled login session to the actual VM for use in managing the defense. This eliminates the Citrix session interaction snooping vulnerability, yet allows the machine to be managed effectively. We wonder if a few other teams employed this method, as we saw no indication that any members of these teams logged into the Citrix server for the entire span of the exercise.

Finally, we think it important to emphasize that the “defensive” and “offensive” aspects of the exercise often proved complementary to one another. As noted, research into offensive methods allowed us to initially harden our system against these same types of attacks. Additionally, the forensic analysis used in reverse engineering an intrusion proved to be the springboard for new approaches on the offensive front. We do not believe this phenomenon to be unique to an exercise such as this: it is a concept intrinsic to any force which fulfills both the role of attacker and defender, dependent on circumstance. It is important to note, however, that a cross purpose force must have effective communication between the actors of the roles: the complementary nature of these activities is only apparent if the information gained is shared mutually.

Problems and Issues

We experienced intermittent network interruptions on our VMs. We believe that this was due to ARP poisoning from the various teams. We also lost two days of trying to access team four’s remote login because of our reluctance to accuse them of not supplying one. As previously stated, one of the virtual machines crashed while attempting to load exploit tools and would not boot afterwards. Additionally, one knowledgeable team member could not actively participate in the penetration testing because his administrative access to the Citrix system could be considered an unfair advantage. Finally, the issue of trust as applied to network resources was a continual and unresolved problem for the duration of the exercise.

Conclusions

In conclusion then, team three was unsuccessful in penetrating team fours virtual machine, though login interception and VMware file exploits were attempted. The team’s machine was successfully defended, although some reason for concern was found with team two’s ability to login to the system. A forensic analysis of this attack points to Citrix session eavesdropping as the most likely source of information leakage. Furthermore, the team found a synergy existed between the defensive and offensive techniques, and used this to increase both its offensive and defensive postures. Some problems were encountered during the exercise: most notable was network connectivity issues, and a missing team member. Finally, it was determined that a significant error was made in not mapping the lab network in its “normal” state, as no pre-existing baseline existed by which to judge trusted resources.

Charts, Tables, and Illustrations

Figure 1: Annotated screenshot submitted as proof of team two’s intrusion.

Figure 2:  MAC address changes noted between command execution intervals.

References

Bailey, M. W., Coleman, C. L., & Davidson, J. W. (2008). Defense Against the Dark Arts. Proceedings of the 39th     SIGCSE technical symposium on Computer science education, 315-319.

Casey, E. (2006). Investigating sophisticated security breaches. Communications of the ACM,49(2) 48-54.

Davies, J. (2005, December 27). Chapter 13 – Internet Protocol Security and Packet Filtering . Retrieved July 24,     2009, from Microsoft Technet: http://technet.microsoft.com/en-us/library/bb727017.aspx

Gates, C. (2009). Tutorial: MS Terminal Server Cracking. Retrieved July 23, 2009, from The Ethical Hacker: http://www.ethicalhacker.net/content/view/106/24/

Gilman, C. (2004). LMCrack – cracked in 60 seconds. Hitchhiker’s World, 9, Article 4. Retreived July 28, 2009, from http://www.infosecwriters.com/hhworld/hh9/lmcrack.htm

Hohl, F. & Rothermel, K. (1999). A protocol Preventing Blackbox Tests of Mobile Agents. Tagungsband der ITG/VDE Fachtagung Kommunikation in Verteilten Systemen (KiVS’99). Springer-Verlag.

Holland-Minkley, A. M. (2006). Defense Cyberattacks: a Lab-Based Introduction to Computer Security.  Proceedings of the 7th Conference on Information Technology Education, 39-45.

Jackson, J. (2008, February 28). VMware vulnerability allows users to escape virtual environment. Retrieved July 24, 2009, from Government Computer News: http://gcn.com/articles/2008/02/28/vmware

Microsoft Security Bulletin MS02-051. (2002, September 18). Retrieved July 24, 2009, from Microsoft:  http://www.microsoft.com/technet/security/bulletin/MS02-051.mspx

Microsoft Security Bulletin MS05-041. (2005, August 9). Retrieved July 24, 2009, from Microsoft:    http://www.microsoft.com/technet/security/Bulletin/MS05-041.mspx

Russel, C. (2004, March 26) Migrating UNIX Applications to Windows via Microsoft Services for UNIX. Retrieved   July 28, 2009, from Microsoft Technet site: http://technet.microsoft.com/en-us/library/bb463202.aspx

Upton, S. C., Johnson, S. K., & McDonald, M. J. (2004). Breaking Blue: Automated Red Teaming Using Evolvable Simulations. GECCO.

VMware Products Multiple Vulnerabilities. (2009). Retrieved July 24, 2009, from Tenable Network Security:  http://www.nessus.org/plugins/index.php?view=single&id=36117

VMware Workstation Shared Folders Feature Lets Users Read/Write Arbitrary Files . (2007, April 30). Retrieved     July 24, 2009, from Security Tracker: http://www.securitytracker.com/alerts/2007/Apr/1017980.html

10 comments for “TECH 581 W Computer Network Operations: Laboratory 7, Team 3

  1. jeikenbe
    July 30, 2009 at 4:35 pm

    This team’s abstract could have included more to it. The abstract give a very brief explanation about the purpose of this lab was. They could have explained how this lab ties into all the other labs, why this lab was important, and/or how this lab could be used in situations outside of these labs. Most of the abstract concentrates on the steps involved in performing this lab. In the introduction section of this teams lab report the team explains that to defend against a system you need to know how an attacker attacks a system. They show this by pointing out that to defend their system they will examine how their system is being attacked and defend against another system using information from watching the attacks against their system. Team 3’s literature reviews were written very well. The team was able to tie each article together and show their opinion about each one as well as showing omissions and errors in the articles. The only thing that was missing in the literature reviews was there was very little in tying the articles in with this lab or previous labs. The group then starts their methodology off by explaining their plan for how they were going to secure their target computer. The team chose to harden a Windows XP SP3 operating system using the specialized security, limited functionality option in the NIST documents for this operating system. They also set up secure shell for remote access and hardened that opening using OpenSSH. They also disabled unnecessary accounts and changed passwords. The team also explains why they chose to use the SSH. They explain that this SSH would limit anyone that was able to exploit it to gain access and thus prevent them from compromising their system through it. To further secure their system they copied their VM from the standard location and put it in a different drive and ran it from there. They left a fake copy in the standard drive to misguide an attacker into attacking that one and not their real system. The team then explains how they detected an attack from team 2 and requested to bring down their system to make changes. They then changed the passwords in their system and brought their system back online. Team 2 had issues with the changing of the passwords in that they believed that even when the system was brought down no changes could be done to that system. The professor ruled in team 3’s favor and team 3 was not penalized. After sending the professor the necessary information the team rejected any logs from then back to the beginning of the exercise and no attack was discovered from there on. Next team 3 planed out their attack against team 4. They started by researching information from previous labs that team 4 posted for any information that would reveal a vulnerability in their system. Using previous labs they make a guess that team 4 would be using Windows XP SP3 as their target computer. The team then proceeded to scan team 4’s computer using Nmap and Nessus. They believed that the scans would not be detected if they scanned the computers late at night. The scans were detected using firewall log files though. They did not find any open ports to exploit, doing the active scans. Team 3 did not mention that they attempted to set up a passive scan on the target system, in an attempt to capture any packets coming out of the system to use for reconnaissance. If the team would have had a passive scanner on the system at the beginning of the exercise they might have caught some traffic from a couple of web browsing that happened early on in the exercise. The team did come up with a clever idea of stealing the VM from team 4’s files and using that VM to extract any passwords or usernames to be able to open up the VM and get any other information they needed to compromise the target computer. This did not work because the files for the VMs could not be copied. Team 3 also tried to exploit VMware itself using a path traversal vulnerability, but the vulnerability kept locking their system up when testing it out on an Ubuntu machine. Team 3 then noticed that the states of the ports went from “no open ports” to “all ports are filtered”. This change caused team 3 to cry foul against team 4 and they requested the professor to inspect the system for changes. It was determined that even though team 4 did not change the firewall they did not provide a remote login for the professor. The professor penalized team 4 and team 4 created a remote login access for the professor. Team 3 discovered that the remote login that team 4 created provided a listening port on port 3389. Team 3 attempted to exploit this port through a couple of old exploits, but was unsuccessful. They also tried to capture any login attempts to the target computer using a man-in-the-middle attack and ARP poisoning. The team also looked into using brute force on the remote desktop login. They tried several different programs, but were unsuccessful. Other means of penetrating the target system were looked into. These involved things like trying to gain access to the Citrix environment under one of team 4’s user names, or pretending to be the professor and gaining information that way. Even if they were able to get in using the Citrix environment, they would have had to crack the username and password to gain access to the target computer. They opted out of these choices because they believed them not to be included in the scope of this lab. Even though the team did not detect the exploit file in the root drive of their computer, they decided on a forensic evaluation on their system, because of the compromise they detected. In the forensic evaluation they noticed that a file was left on their desktop from team 2. They ether suspected the professor or it was an attempt to plant a file from which team 2 would be able to exploit their system from. They determined the latter. They also made it clear about the amount of ARP poisoning going on over the network. The team suspected that team 2 used “PuTTY” to gain access to their computer and monitored the connection for vulnerabilities in their system. Team 3 could not conclude to this idea. The team then hints to the possibility that team 2 was able to gain vital information through capturing of verbal information or “over the shoulder peeking”. They later decided that this was probably not the case. They also investigated the possibility of team 2 cracking the schools e-mail accounts to gain information from e-mails being sent between team 3 members. The team also examined the possibility of the use of brute force, but this was ruled out due to the complexity of their password and the amount of time involved in this lab. In the end the team believed that the compromise was due to team 2 gaining access to one of team 3’s Citrix accounts and a brute force of their accounts allowed them access to their target account. In the methodology for this teams report they provided too many results. These results could have been included in the results and findings section of this report. The whole forensics analysis could have been included in the results section. This group could have reduced the methodology section down by just explaining the plans for how they were going to secure their system, how they were going to attack the target system, and how they were going to do their forensic evaluation. In the results the team starts off by recapping information that was given in the methodology about how they were compromised by team 2. The team then explains that how without traffic from the target computer and no user behind the computer, the system would be almost impenetrable. The team then talks about how they should have gotten a map of the network before the attacks started so that they could have known which computers were what. The team also examined the idea of using a VPN to the lab network to protect against any sniffing on the Citrix sessions. The team concludes the results by rehashing what they said in the introduction of using what they find out about attacks being made on their systems to harden their own system. Some issues that team 3 provided were network interruptions, loss of time to exploit team 4’s computer due to not crying foul earlier, a virtual machine crashing and not booting again, one of the team members being removed from the exercise due to the account privileges given to him, and the issue of being able to trust what was on the network. In the conclusion of team 3’s lab they rehash everything that was accomplished in this lab. The conclusion could have been written better. Instead of just summarizing the lab, the team could have explained some concepts that they learned while doing this lab.

  2. mvanbode
    July 30, 2009 at 7:07 pm

    I do not believe that stating that your team is doing a literature review is necessary. How do you implement the machine? The abstract was not the required length. Once again if the team had put some of their introduction into the abstract they would get the required length. I like how the team mentioned that literature was consulted and reviewed. Did the team find literature outside of what was handed to us to consult and review? The only other document should have been the security guide that the team followed. If they used other documents than what they picked for their previous lab, then they did more than what they were supposed to. It was different that the team stated how their literature review was going to be laid out before actually beginning the literature review. While the purpose of the lab was to teach the teams about anti-forensics, not a single team seemed to be able to successfully attack another machine, so no team was able to do some research into the attack. Also this means that since no team was successful, no team was able to perform some anti-forensics. Team 3 tried to make a cohesive literature review but failed. It read like a list. Not all of the required questions were answered. The team did talk about the articles decently. The team did not relate the articles to this week’s lab experiment properly. I would say in the future to make sure to follow the requirements for the lab but this is the last lab report.
    It was nice of team 3 to think about the other teams when choosing their target machine. Does installing other software go against the lab experiment? Some would say that this completely went against what the teams were supposed to do. I would have to agree with team 2 crying foul to team 3. Even after team 2 was able to put a file onto team 3 machine, but the team took the machine down and made changes. It is something that team 3, even though they knew it was against the rules, they still researched the ‘illegal’ ways to exploit team 4’s machine. I found it interesting that team 3 investigated heavily into how the mysterious file was placed on their machine. Their only logical conclusion seemed to be that team 2 used unethically means of obtaining system information. I would like to know what team 3 thought the attacked used was after reading team 2’s lab report. Does the team really believe that other teams performed ARP poisoning against them?

  3. nbakker
    July 30, 2009 at 7:50 pm

    Team thee again presents an abstract that is not within the bounds of the syllabus. While it does explain what is going to be accomplished in the lab exercise, it is not the minimum required number of paragraphs. The syllabus states that any abstract shorter than two paragraphs will be judged as poor scholarship. Based on this, and their lack of a good abstract in any lab report, I question the overall scholarship of team three. The introduction by team three to the lab exercise is well formatted and fits nicely with the lab. The literature review however is slightly lacking. Team three makes an attempt to provide a good level of cohesion among the articles, but does seem to fail here. The articles as presented are listed one by one with an explanation of each to go along with it. Team three attempts to link the articles together between unrelated paragraphs, but again as stated before, they fail in this regard. Team three’s literature review amounts to almost nothing more than a list of articles with APA style citations. This does not make for an academic or scholarly literature review and does not add to the value of the lab report. I also fail to see where team three ties the articles for review into the actual steps of the lab report. The articles presented for review each week are supposed to be connected to the activities of the lab completed by the team. In this regard team three also fails. The methods section provided by team three do a very good job of explaining the how and the what of the steps performed by team three in the lab, but do a poor job of explaining the who when and why. A Good methods section should allow experiment reproduction by anyone with sufficient knowledge, and without answers to the five basic questions, good reproduction is really not possible. The methods and findings section regardless of the lack of these questions is still rather complete and does a very good job of explaining the steps they took to both defend their host and attack team four. I do however question the usability of a Windows network server running nothing more than OpenSSH, getting any work done on a remote server that centers around the use of a GUI would be impossible using openssh. Team two did allow Remote Desktop Connections to the full and unrestricted server desktop, and was not successfully hacked. Team three displayed a very high level of paranoia in their lab write up, especially around the areas of a sideways attack through Citrix. If team three was intelligent enough to discover how to copy a VMDK, attach it to another VM and crack the SAM in that VMDK, then they should also have been intelligent enough to right click and select properties on any of their VM folders and go to the security tab. A simple visual inspection there would have indicated that only they had access to do anything more than “list” at the files present in those folders, and their paranoia could have been abated. Team three’s forensic investigation is very complete even though it is entirely inaccurate.

  4. tnovosel
    July 30, 2009 at 9:11 pm

    In the abstract section of the laboratory report, team three gave a brief overview of what was accomplished in the final lab exercise.

    In the literature review section, team three pointed out that the true meaning of this lab exercise was to perform anti-forensics when they stated “While the majority of this week’s activity dealt with attacking other teams’ systems, the real intent of the lab experiment was to expose the students to anti-forensics, the art of hiding one’s tracks.”Team three was able to relate the articles to each other.

    In the methodology section of the laboratory report, team three revealed that they used Windows XP service pack three as the system they would harden. Team three was able to harden the system via the Microsoft Specialized Security, Limited Functionality (SSLF) Workstation group policy for XP SP3 as per “Security Compliance Management Toolkit: Windows XP” ,enabling the firewall with only a single port for Secure Shell (SSH) being opened for their OpenSSH server , disabling the Microsoft file sharing service and all existing user accounts were disabled, including the default “Administrator”; with two accounts being added, one with administrative privileges and one without, both with high complexity passwords to prevent brute-force cracking attempts. After being attacked by team two, team three during their downtime, changed systems passwords, which was an acceptable action, but incurred the wrath of team two. Team three changed the SSH client side software to reject connections which did not use SSH version two. Team three used a variety of techniques to try to exploit team four’s system It was odd that group three had stated “A network scan of the target system on Friday showed that the results of the scan had changed from “no open ports” on Thursday to “all ports are filtered” on Friday.” The firewall had been one of the first items activated before the IP address was given out on Wednesday night. Because of a misinterpretation of the lab instructions, team four did not initially include an avenue of remote login, which incurred the wrath of team three. However, even when Windows remote desktop was activated, it seemed impervious to the cracking tools that were employed by team three. Team three then listed other ways that were outside of the scope of the assignment that they could have used to acquire group four’s passwords including intercepting e-mail messages and spoofing the Professor’s e-mail address.

    In the results section, team three accounted team two gaining getting the user name and password by monitoring of the team three’s Citrix sessions. Team three stated “With relation to this exercise, the team must admit that with the benefit of hindsight, we would change a number of things with regard to methods and preparation. There can be no doubt that it was a mistake on this team’s part not to map the network which served as the “battlefield” well before the action began. As we did not know what the “normal” network should look like, we found it difficult to ascertain when something was amiss.” My team had made the same mistake also and was not made aware of the network manipulation until wireshark and other scanning tools picked up unusual network activity during the hack wars.

    In the issue section, team three came across several problems including network interruptions, crashing virtual machines, issues with their target system, and the inability of a group member to participate because of his administrative circumstances.

    In the conclusion section, team three restated some of their issues and stated that “the team found a synergy existed between the defensive and offensive techniques, and used this to increase both its offensive and defensive postures.”

  5. July 30, 2009 at 11:32 pm

    Group three’s literature review accurately identifies the main points of the lab exercises and reviews each assigned article with relation to the lab activities. Not all of the articles are handled as well as others but the write-up flows nicely between then rather than isolating the content of each paper to a paragraph. Team three had some excellent insights into the content of some of the assigned readings, particularly “Cyberattacks” and “Defense Against the Dark Arts.” The notation of the lack of an ethics section was further supported by the team’s assertion that the author’s use of “edgy” material to draw in students was unethical.

    Team three broke up their methodologies into three main sections, defense, attack, and forensic investigation. The defense section was very well documented. One omission in the section on using the SSLF template was the lack of supporting documentation or citations. Where did this come from, the Microsoft guide, the NIST guide, or somewhere else? The use of OpenSSH to facilitate the remote access requirement is a little unclear. If it’s limited to an unprivileged account how is the instructor supposed to validate the configuration? Team three’s response to the intrusion by team two leaves many questions. If the point of the lab exercises is for the attacking team to use anti-forensic methods to cover an intrusion and for the defending team to attempt to recreate their attack methods, wouldn’t it have been better to gather as much data about the attack as possible as it was occurring? From the analysis in the lab, team three has no idea how the intrusion occurred and is merely guessing at (valid) potential methods. The point of the lab wasn’t necessarily to successfully defend the machine against attack. Though a compromised machine would lead to more work for the team in reconstructing the attack, the write up makes it seem more like team three believed they’d “lost” if team two succeeded. Had team three successfully traced the methods team two utilized, the true purpose of the lab could have been realized.

    The attack section provides a well thought out plan of attack utilizing all of the materials learned previously in the class. One issue I had was the port scans late at night as there was less chance of it being monitored. What if they’d used another machine to run the port scans from and saved the logs in capture dump files? Active monitoring of the systems, though possible, would require a significant time investment for the defending team. As you said previously in your literature review “a security breech is inevitable, and that good forensics practice may help locate the parties who carried out the attack.”
    The forensic investigation of the machine, I feel, was done too late. Only after team two called “cheating” did team three increase their network reconnaissance. Had this been done immediately as a response to the attack I think the analysis would have been more revealing.

  6. mafaulkn
    July 31, 2009 at 10:56 am

    Team 3’s abstract is well written and gives a good overview of what they will be attempting in lab 7. As always team 3’s introduction is good, and is a summary of all of the previous lab activities and how they tie into lab 7. The literature review is not as cohesive as perhaps it should be however, each article is summarized in detail and the group compares and contrast the articles and gives their opinions on the information presented stated in the articles.
    Team 3’s methods section is very detailed. I like how team three broke up their methods section into three sections. The “Plan of Defense” section is well documented and gave specific details into why they chose to use a Windows XP SP3 machine. They indicated that their team members more proficient in a Microsoft NT environment and felt anti-forensics would be easier using their chosen environment.
    The “Plan of attack” section provided detail needed for their plan of attack I like the fact that before their red teaming exercise began they utilized Professor Liles’ blog to start passive reconnaissance by inspecting the previous laboratory reports that had been submitted by team 4. They used this information to determine possible information leakage of operating system type, passwords and security methods used in previous labs. I thought it was very creative how team 3 used previously provided material required in lab 5 by team 4 against team 4 in lab 7. Laboratory five had required each team to choose an “as-is” operating system and attempt to exploit it. Again as they had mentioned in their introduction team 4 used previous lab experience for lab 7.
    The “forensic investigation” section was also well documented. Team 3 felt that forensic investigation was challenging due to the fact that their Virtual Machine was not compromised. They were able to identify intrusions but couldn’t ascertain whether it was another team or Professor Liles testing for compliance. They eventually confirmed it was the work of team 2 as detailed by in their figures 1 and 2.

  7. shumpfer
    July 31, 2009 at 12:49 pm

    The team begins with the abstract and explains what is going to occur within the lab. They provided a small abstract. They then went onto their introduction discussing the subject of the best defense is a good offense. With this they discus from it to create an utilize a plan of attack. They then go onto discuss the literature review and not only how it relates to this weeks lab but included the previous six and how in each methodology there are patterns to look for and how the related to the class. They then go on and through out the literature review they discuss the different methodologies and reference the literature. This created a more interesting review, along with comparing and contrasting. Although there was still some separation in the review it was a good one to end the class on. They then go on to discuss the methodologies and what was done to harden their system and then what was going to be done to exploit the targeted system which was team 2’s. They broke the section down into three smaller subsections the first was plan of defense, then plan of attack, and finally forensic analysis. Each of the sections where described in detail and again shows the strong point for this team. Next the team provided the findings. Here they stated that they where unsuccessful in exploiting the target system. Although the team was not successful they described the benefits of doing an exercise such as this. I agree that planning the attack is just as important as the actual attack its self. Many times attacks would fail due to lack of planning and the lab has shown each team this. They then provided their issues and concluded with an overall summary. From the findings section their where statements that could have made the conclusion stronger. Some of the information provided in the conclusion could have been placed within the issues and problems section. Overall the team did a good job.

  8. prennick
    July 31, 2009 at 3:36 pm

    I think that group 3’s write-up for lab 7 was good. The abstract and introduction for this lab was very good. The literary review was somewhat very good. Group answered all of the required questions for the literature review. All of the citing for the literary review was present, but not proper throughout the lab. The literature review was cited properly throughout. The author and year of the reference was included and all of the page numbers were present. For this lab, the group answered all of the desired questions. The group covered all of their steps in great detail. However, some more detail should have been covered about how exactly ARP poisoning was performed using Cain and Abel. This is because by poisoning the whole subnet, the group could have broken some of the rules. Forcing the entire subnet’s traffic through a virtual machine is a destructive attack and can bring the whole subnet down for some time. The group did indicate many good points such as how they found evidence of a lot of ARP poisoning by other groups. This indicates that other groups could have redirected traffic from other attack groups to an incorrect virtual machine. Finally, the conclusion to this laboratory was also well done because it accurately sums up their procedures and findings.

  9. chaveza
    July 31, 2009 at 4:04 pm

    Team three decided to use a kernel Microsoft NT kernel based environment because the team felt they were more proficient and performing forensics on a Microsoft environment would be easier to do. The team decided to use Windows XP SP3 as there target node. They protected the OS by enabling the firewall and only allowing SSH port to be open. They also identified that the team followed “Security Compliance Management Toolkit: Windows XP” which the team identified came from lab five. The team also added two usernames, one having administrative privileges while the other was a regular user and disabled the rest of the accounts. According to team three this defense policy was not successful. The attacking team, team two, was able to log into the virtual machine on day two.
    Team three made some guess about what was done by team four, which was pretty much dead on. This team used Nessus and nmap to retrieve information about what kind of system was being used. After learning that they could not find any open ports the team took a completely different approach and decided to attack VMware instead of the operating system itself. After two failed attempts at attempting to mount a shared folder the team discovered on Friday that the machine went from no open ports to all ports are filtered. From there the team used a verity of tools such as TSCrack, TSGRinder, Cain with ARP poisoning in order to gain login credentials. The team also listed off some really good ideas about exploiting the team at a higher level.

  10. gdekkerj
    August 1, 2009 at 6:08 pm

    To all on the question of the wisdom of changing passwords once an intrusion was detected:
    Many of you raise valid criticism of our actions with regard to team two’s break in. Perhaps we let pride overcome our better judgment in these regards: we felt the need to prove that our system was not breached due to incompetence on our part; and changing the passwords provided an effective way to test this. In reality, the account change was a tactical move to see how circumstances would develop. We could not be certain team two was involved at this point: this was ultimately confirmed by our actions here. As we were able to control the dispersion of the new credentials, we hoped the source of the security leak could be isolated. We thought is possible that team two would somehow acquire the new login: it would have given us more information as to what happening. Though unmentioned in the lab write up (as it came to no result, and shows a degree of paranoia which seems laughable in retrospect), I seeded false credentials in the Citrix environment: depending on what new logins appeared, we would have known a great deal more than what we previously did. Unfortutaly, no additional efforts by team two were made. Ultimately, even if we had not changed the account information and team two had succeeded, the forensic investigation would have been the same as we related in our write up. The weakness was not in the configuration of our system, but in factors beyond our control. The circumstances would stand exactly as they are now, with us making guesses, and team two remaining silent.

    @jeikenbe: I don’t think that we ever stated we monitored team two with regards to “PuTTY” usage: all the “PuTTY” discussion was in regards to our own utilization of the client.

    @mvanbode: the only document package we used to secure the VM proper was the Microsoft document mentioned from lab five. We used other documents (as cited) to plan offensive and defensive actions outside the VM configuration itself. The SSH server was an addition, and as a Linux installation offers this natively, we felt it appropriate to include. It should be noted that the concept of “third party” utilities on Linux is somewhat confusing, as distributions are collections of third party items in a common repository: in this, we felt the same degree of freedom should be allowed for Window’s installations, which is why we discussed Microsoft’s position on SFU and SSH. We understand your criticism of our response of team two, but politely disagree. Your comment on researching “illegal” means to compromise team four: I think team two’s reluctance to reveal their methods speaks sufficiently toward this topic. One should always know what ‘can’ be done, even if you have no intention of using it yourself. We do not know what team two ultimately did to compromise our machine; as this is the end of the exercise, I am content to let the matter rest. Also, who can say what really happened with ARP poisoning during the exercise? However, the team five and two combined attack against your team indicates that alliances were present: so yes, it is likely other teams were ARP poisoning us.

    @nbakker: Your criticism of the “who, when and why” concepts missing from the methodology is puzzling. I believe the “who” is obvious (team three), the “when” irrelevant, other than to denote the order of steps and events when important to the discussion, and the “why” to be sufficiently addressed in most cases. Perhaps if you would have pointed out specific examples I could address this further. The OpenSSH question is a good point: in reality, however, most of the functionality limitation came from the SSLF group policy configuration. While GUI utilization is mostly out of the question (tunneling can be done, but is outside the scope of the discussion), Microsoft does provide a relatively complete set of command tools to configure the operating system. We noticed that your group tried to run the security console (sc.exe); this would normally work except for the default SSLF policy in place on the machine. I really believe your complaint to lie mostly with the SSLF group policy rather than the usefulness of the SSH configuration means. Third party application could be an issue with this configuration, but we had no need to worry about this in the scope of the exercise. The comment on the file permission is interesting. You do realize that the items under discussion are remote file systems, with permission enforced by file server login credentials, correct? I think it becomes obvious how easy it is to get around these permissions on group folders if even one of the target groups’ members credentials is available: it is as simple as mounting a network drive using a different SMB login.

    @tnovosel: the lack of pre-exercise network mapping was a very real problem, and I believe points to the most significant thing learned from the exercise: know the battlefield. I think it commendable that you alone, among all the reviewers, were the only one to present real discussion on this crucial idea: good work.

    @jverburg: many of your criticisms are valid. The document used was examined fully in exercise five, and was specifically named in the methodology section. The login of an administrative account was not enabled, as we saw reason that a survey of system functionality would require more than this. The real limitation came from the Microsoft SSLF group policy kit, which appeared to disallow “runas /user:admin …” or similar from a normal user account. If necessary, we would have accommodated the wishes of Professor Liles (if administrator access was required) should it have come to this. Most of the forensic investigation, including the increased level of reconnaissance actually occurred shortly after team two’s break in. Our group did not request downtime until after this investigation occurred. I think, despite what some parties believe our level of logging was already at a substantially high level: this is what allowed us to reverse engineer the attack to the extent that we did. I think you must admit that in retrospect, due to team two’s undisclosed methods, we would have learned little more had we let the attack progress: our forensic report would be essentially the same as its present form in nearly all respects.

    @prennick: the approach with the ‘Cain’ program was this: we poisoned all observed hosts into believing we were team four’s machine, other than the network gateway (we didn’t know the amount of traffic flowing through the gateway route, and did not want to cause a DoS on team four’s machine). Not much traffic was actually affected (only the traffic to and from team four’s machine, of which little was recorded). Most of the other traffic was picked up without ARP poisoning, due to our location on the shared Citrix server resource. The time rate of our ARP poisoning transmissions varied, generally between nine and thirty seconds. We were forced to choose shorter intervals, as other ARP poisoning sources appeared to be “stealing” our targeted data streams by utilizing shorter ARP broadcast intervals. I cannot see how we would be a factor in the team five/two against one mix-up, as we were not in any way altering team ones MAC address.

    To all: thank you for an interesting semester. I am sure we will see more of each other in the future.

Leave a Reply