The first part of the lab is to research passive reconnaissance tools and how they operate. The students will identify if the tools can or cannot recreate the packet stream passively. The ability for tools to change the duration of their tests will be covered. The importance of the ability to change the duration of a test will also be discussed. The next part of the lab will include the research of scanning tools, such as Nmap and Nessus. These tools will be tested to see if their scanning results can be detected on another system using a packet sniffer. The student will also discuss operating system biases for these tools and how the exploits that they perform relate to the security tools grid. The methods and results of this test will be discussed in detail. For the last part of the lab, a set of case studies will be discussed, based on research of network penetration tools that have been exploited. The risks to the enterprise that use untested or exploited tools in penetration testing will also be discussed. The student will discuss all of their findings and report any issues and problems encountered in the lab.
Passive reconnaissance tools are tools that watch other systems without the victim system knowing that they are being watched. Passive reconnaissance tools can be used for blackbox testing as well as whitebox testing. Blackbox testing is the act of purposely injecting errors, from an outside perspective, into a system to find any problems within it. Whitebox testing is the same method as blackbox testing but it looks at the inside perspective. Both of the papers that were the required readings dealt with blackbox and whitebox testing. One does deal Privacy Oracle while another talks about random testing and blackbox vs whitebox testing.
Patrice Godefroid got invited to the 2007 annual meeting at Internal Workshop on Random Testing. The proceeding of her discussion can be found in the article called Random Testing for Security: Blackbox vs. Whitebox Fuzzing. In the first part of the article, Godefroid discusses the idea of blackbox fuzz testing. Fuzz testing is the act of randomly mutating well-formed inputs and testing the program on the resulting data (Godefroid, 2007, pg1). The author purposed an alternative to whitebox fuzz testing. The author setup a model for comparing whitebox fuzz testing to blackbox fuzz testing. In the conference the author makes the comparison to the audience of the conference. This is different from the idea that Jung et al brings up in their article about Privacy Oracle: a System for Finding Application Leaks with Black Box Differential Testing. Jung et al talks about their approach to find any information leaks with Privacy Oracle by using Black box differential testing as opposed to Godefroid proposal to use whitebox testing (Jung, 2008, pg279).
Godefroid believes that the best approach to testing an application or system is to look at the inside perspective of the attacks on them instead of the blackbox which looks at the attacks from the outside perspective. Godefroid introduced her idea of SAGE testing, which stands for Scalable, Automated, Guided Execution (Godefroid, 2007, pg1). The author goes on to talk about that in the early stages of this model that they have already found over 30 new bugs found in Window applications such as image processors, media players and file decoders (Godefroid, 2007, pg1). I think Godefroid may be right about her approach to whitebox testing. I think the best way to test the system is to see it from the inside perspective as opposed to blackbox testing, while looks at it from the outside perspective, which Privacy Oracle does.
Privacy Oracle is a tool that reports on application leaks of user information via the network traffic that they send. Privacy Oracle treats each application as a black box, without access to either its internal structure or communication protocols. This means that it can be used over a broad range of applications and information leaks Jung, 2008, p279). Jung et al found that right after the installation that Privacy Oracle found numerous information leaks when they tested 26 different popular applications. The main idea of Privacy Oracle is to look at some of the most common applications that people put on their personal computers and find what kind of information is leaked from these applications that can be used to steal their identity. While some of the information that can be found in these applications can be useful to help the individual, some of the information can be used for harmful activities (Jung,2008, p279).
Jung et al set out with a goal when writing this article and that is to help develop tools and techniques to help enable them find personal information leaks in the applications that they use (Jung, 2008, p279). This goal will be accomplished by the authors by creating and implementing a fully automated suite to find the exposure of personal information leaks in these applications. The first part of the test is to use Privacy Oracle to find the information leaks. The second part of the test is to study and take apart what information is leaked from the applications that Privacy Oracle tested (Jung, 2008, p280). The authors go into detail about how the blackbox difference testing with work in their experiment. The output analysis is studied and algorithms are used to determine the probability of the occurrence of the event happening and personal information is leaked from the application. One of the main algorithms used by the authors is the NetDialign, which is the authors’ take of Dialign. The tools that the authors studied and tested are as follows: Ad-Aware 2007, OneClick iPod Video Converter, Advanced WindowsCare, Real Player, AOL Internet Messenger, Spybot, Avant Browser, VersionTracker Pro. Avast Home Edition, IrfanView, AVG Anti-Virus Free Edition, iTunes Media Player, BearFlix, Limewire, BitComet, MediaCell Video Converter, Camfrog Video Chat, Morpheus, DivX, Windows Media Player, Gmail, WinRAR, ICQ, WinZip, Interactual Player, Yahoo! Messenger (Jung, 2008, p284).
Some of the findings that Privacy Oracle found is that in many of the applications tested asked for personal information such as e-mail address, name, age or gender. All of these items can be used to help steal the person’s identity or at least help someone else masquerade as the individual as far as the applications are concerned. The authors go on to discuss the effectiveness of Privacy Oracle as well as their algorithm called NetDialign. Although this group finds that whitebox testing is the better than blackbox testing, the Jung et al give a good counter side of why people would want to use blackbox testing. The authors state that the downside of this method of blackbox testing is that their method could have a bad effect of the programs that were tested. Privacy Oracle is a good tool use for blackbox testing but it does have its downside as many pieces of software do that perform penetration testing. It can raise the question does the software itself need to be tested before it can be used to test other application?
Methods Part 1
|OSI 7 Layer Model Layer||Tool Name||McCumber Cube coordinate|
|People /8||Dumpster diving, social engineering||Confidentiality, processing, policy|
|People/8||Following FedEx, Telescope, binoculars,||Confidentiality, transmission, human|
|People/8||Stealing mail||Availability, storage, human|
|Application /7||Mbenum, netenum, psinfo, psfile, smtp-vrfy, amap, p0f,, sinfp, unicornscan, xprobe2, zenmap, pasco, sleuthkit, vinetto,||Confidentiality, storage, technology|
|Application /7||Getsids,halberd, httprint, httprint gui, metoscan, mescal http/s, mibble mib browser, onesixtyone, openssl-scanner, smb serverscan, vnc_bypauth, wapiti, 3proxy, gdb server, gnu ddd,||Confidentiality, processing, technology|
|Application /7||0trace, relay scanner,||Confidentiality, transmission, technology|
|Application /7||Gfi languard, ascend attacker, cdp spoofer,||Integrity, processing, technology|
|Application /7||Goog mail enum, google-search,||Integrity, transmission, technology|
|Application /7||crunch dictgen,||Availability, processing, technology|
|Presentation/6||Finger google, googrape, maltego, metagoofil, bruteforcer,isr-form, list-urls, sidguess, collision, wyd, xspy||Confidentiality, storage, technology|
|Presentation/6||dcfldd, dd rescue,||Confidentiality, processing, technology|
|Presentation/6||Sql scanner,||Confidentiality, transmission, technology|
|Session/5||Airodump-ng, airsnort,||Confidentiality, storage, technology|
|Session/5||Packet,||Confidentiality, processing, technology|
|Session/5||Dnstracer, tcptraceroute, tctrace, ike-scan, , superscan,||Confidentiality, transmission, technology|
|Session/5||Thc pptp, tcpick, urlsnarf, hotspotter, karma, pcapsipdump,||Integrity, storage, technology|
|Session/5||carwhisperer, minicom,||Integrity, processing, technology|
|Session/5||sipdump, sip,||Availability, processing, technology|
|Transport/4||Dnswalk, mboxgrep, memfetch,||Confidentiality, storage, technology|
|Transport/4||snmp scanner, httpcapture, mailsnarf, smb sniffer||Confidentiality, transmission, technology|
|Transport/4||Icmp redirect, icmpush, igrp spoofer, irdp responder, irdp spoofer, wireshark, wireshark wifi, icmptx, pcaptpsip,||Integrity, processing, technology|
|Transport/4||Firewalk,||Integrity, transmission, technology|
|Transport/4||Smb dumpusers,||Availability, processing, technology|
|Network/3||dnspredict, subdomainer, angry ip scanner,||Confidentiality, storage, technology|
|Network/3||protos,||Confidentiality, processing, technology|
|Network/3||Ass, Autoscan, genlist, cryptcat,netdiscover, Whois, netdiscover, nmap, scanmetender, superscan, unicornscan, nhs nohack ,ping, protos, scanline, scanrand, revhosts, dnsspoof, driftnet, etherape,netsed, netenum, netmask, ntop, sing,smap,||Confidentiality, transmission, technology|
|Network/3||ltrace, yersinia,||Integrity, transmission, technology|
|Network/3||Spike,||Availability, processing, technology|
|Data Link/2||host, nmbscan,||Confidentiality, storage, technology|
|Data Link/2||Tftp brute,||Availability, processing, technology|
|Physical/1||wiassistant, hstest,||Integrity, transmission, technology|
Snort is a tool that is able to recreate the packet stream passively. The purpose of this is to be able analyze the data streams to find any signatures that indicate an attack is underway. Other IDS tools also have this ability. Another tool that has this ability is Netperf. This reason for this tool as well as any others that have the same ability is to ensure that if an attack occurs, the packet streams will be able to be recreated. One can make a script or tool slow down by setting the time for the attack to take longer. It all depends on the tool whether it is better for the attack to take longer than milliseconds. Generally, it will be easier to detect a script or tool if it takes milliseconds. If the tool or script takes longer, it will be harder for the data streams to be recreated because the attack traffic may appear to be legitimate traffic. Though, it will still be considered active as opposed to passive.
Methods Part 2A
First, Nessus and Nmap were installed on a Linux virtual machine running Ubuntu Linux. Invoking the following command performed the installation of Nessus and Nmap: “sudo apt-get install nmap nessus nessusd nessus-plugins”. Once these tools were installed, a registration code was required to update the plugins. The registration code was obtained from http://www.nessus.org/plugins/index.php?view=register. Next, Nessus was registered by entering the following command: “nessus-fetch -register [registration code]”. Next, the plugins were obtained using the “nessus-update-plugins” command. In order to run Nessus, a user account must be created in order to login to the Nessus server. Invoking the “nessus-adduser” command and entering a username and password created a Nessus user account.
In order to run Nessus, the nessusd daemon must be running (either on the local host or another server). The nessusd daemon was started by invoking the “sudo nessusd &” command (or it can be started using “/etc/init.d/nessusd start”). Nessus was then started using the “nessus &” command. Once the Nessus application had launched, it was logged into the server (running on the local host) using the credentials created with the nessus-adduser command. Next, under the “Plugins” section, all plugins were chosen. Then, under the “Targets” section, the IP address of a Windows XP SP3 virtual machine was used (192.168.1.1). The scan was then started and a report was created. Next, the command: “sudo nmap -sS -O 192.168.1.1” was used to perform the Nmap scan.
Nessus scans approximately 1000 types of vulnerabilities. This does allow an attacker sieve the information more quickly. This is because it only takes a few packets for Nessus to discover a vulnerable port on the target system. I think that if the Nessus vulnerabilities were put into a grid, like the tools have been in previous labs, patterns would emerge. Just like the security tools fit into the OSI model, the specific attacks will also fit. Different attacks will fit into the OSI model at different layers, depending on what protocols they are using and in what layer in the OSI model can they be exploited.
Nessus and Nmap have some biases based on the operating systems they test. Based on the numbers obtained from http://www.nessus.org/plugins/index.php?view=all, most of the vulnerabilities pertain to Windows operating systems (Tenable Network Security, 2009). However, there are plugins for testing all sorts of operating systems. I think the reasons for the large amount of plugins written that target Windows systems are because of the success of the operating system. People who use Nessus write the plugins. If there are more Windows clients and servers that need to be tested, there will be more plugins written to test those machines. When considering biases pertaining to Nmap, I think it follows a similar model. While Nmap simply looks for open ports, regardless of the operating system, the community controls the operating system detection. Users who submit known operating system fingerprints to the Nmap database can help to properly identify future OS detection in Nmap.
After the initial scans were performed, the scans were performed again. This time, the scans were captured using Wireshark. Before the captured scan was started, Wireshark was launched on a BackTrack virtual machine by typing “sudo wireshark &” into the terminal. Once Wireshark launched, it was set to capture all traffic on the eth1 interface, which is the adapter for the private network (192.168.1.0/24). Next, the Nessus security scan was started. Once the scan completed, all packets captured in Wireshark were saved and a report was created in Nessus. Then, in Wireshark, a new live capture was created. This time, Nmap was used to scan the Windows XP SP3 virtual machine. The command used to start the Nmap scan was: “sudo nmap -sS -O 192.168.1.1”. Once the scan was complete, the Wireshark capture was saved.
After reviewing the telemetry gathered by Nessus and Nmap, one can see that the scans can clearly be captured. Wireshark was chosen as the method for capturing network traffic instead of dsniff, because Wireshark is a general too, while dsniff looks for specific data in packets, such as passwords. Since all of the packets are captured in real time, both the packets being sent from the machine running the security-testing tool and the replies from the machine being audited can be seen. For instance, consider the following packet information, which was captured during the Nessus security scan with Wireshark:
No. Time Source Destination Protocol Info
15 6.997810 192.168.1.2 192.168.1.1 TCP 55158 > 3com-tsmux [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=89034 TSER=0 WS=5
Frame 15 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: Vmware_bb:75:ac (00:0c:29:bb:75:ac), Dst: Vmware_76:2e:9a (00:0c:29:76:2e:9a)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
Transmission Control Protocol, Src Port: 55158 (55158), Dst Port: 3com-tsmux (106), Seq: 0, Len: 0
No. Time Source Destination Protocol Info
16 6.997931 192.168.1.1 192.168.1.2 TCP 3com-tsmux > 55158 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
Frame 16 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Vmware_76:2e:9a (00:0c:29:76:2e:9a), Dst: Vmware_bb:75:ac (00:0c:29:bb:75:ac)
Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 3com-tsmux (106), Dst Port: 55158 (55158), Seq: 1, Ack: 1, Len: 0
Of course, what is shown above is not all of the packet data (though all of the packet data WAS captured), but one can see both parts of the communication. Also, detecting that this is in fact a Nessus scan is easy, due to the fact that it runs through many different ports and protocols very quickly. The same technique works with Nmap. Using this data, an attacker can simply search the capture file for all protocols or ports they are known to be vulnerable or easily exploitable and read the packet data to determine the outcome of that port or protocol’s security test. As long as the vulnerability types are known, a port/protocol list can be used and when this traffic matches activity on the network, it can be determined that a Nessus scan did, in fact, occur. Studying the Nessus traffic is important for an attacker. Even if a Nessus scan occurs, if the network is already saturated with data, it may be difficult to sieve all of the important information. Therefore, an attacker should study how Nessus operates, to understand what packets are used and how many are used to determine vulnerabilities, in order to find meaningful data amongst much meaningless data.
What can one use the capturing of legitimate data for? Capturing legitimate data can be used by an attacker to discover vulnerabilities in the network without allowing their presence to be known. In addition to simply capturing all data on a network and waiting for a Nessus scan to occur, there is an easier way to obtain this important data without capturing all data. A tool such as Snort can detect when a port scan is occurring and can be configured to generate alerts or run commands when detected. This tool could detect the Nessus scan and then begin to capture all packets to and from the machine running Nessus. When an attacker performs an Nmap or Nessus scan against a network, it’s a good idea to slow down the attack to prevent an IDS system from detecting the scan. This method may also be beneficial to security testers to help prevent attackers from obtaining telemetry from the scan and exploiting it before the security tester can properly patch the security holes.
The results of this test show that it is, in fact, possible to gain telemetry from an active tool by using a passive tool. This is because both the request and response can be captured, and therefore dissected in order to recover the results of the scan. This test also concludes that tools such as dsniff are not as effective because of their specific nature for retrieving certain types of data rather than packet all of the packets sent to and from a machine running Nessus, like Wireshark does. However, when considering the infiltration of legitimate security audits, IDS tools such as Snort may provide a good method to automatically sift out unimportant packets. This lab indicates the importance of viewing the packets used in a Nessus scan to determine how to detect a scan and how to determine vulnerabilities using a passive tool rather than an active tool. This is important because it allows an attacker to remain silent on the network while performing a reconnaissance attack. This, of course, raises the question “How does one detect an attacker performing active reconnaissance or, at least, minimize the information available to the attacker.” While machines in promiscuous mode can be detected, it can sometimes be difficult to detect. Therefore, machines in promiscuous mode should be searched for, but the existence of an undetected promiscuous node should still be assumed. Also, active security tests should be performed, as an attacker would. By minimizing the obviousness of a security test being performed, the likeliness of an attacker using passive reconnaissance exploiting this telemetry will also me minimized.
Open-source tools are an economical way to test the security of your network; unfortunately they’re available to both ethical and unethical attackers. (Ballard, 2006).
The good news is that there are plenty of open-source tools available to test the security of networks and alter network settings. They’re freely available as part of OS or over the Internet, and they usually cover a wider range and scope than off-the-shelf security products. And, often, these open-source tools have more features than comparable commercial options (though this can mean more complexity). In general, these tools are easy to acquire and install (Ballard, 2006).
The bad news is that would-be attackers know about and have access to these tools, too. Therefore, it’s imperative that one must know how intruders can use these tools against them and how to recognize when one is at work in your network.
Open-source network security tools fall into three main categories: those that probe the network; those that listen on the network; and those that alter the network (Ballard, 2006).
Although my research led me to a variety of open source penetration tools that have now become attack tools I’m focusing on Metasploit, John The Ripper 1.0, and NetCat.
Metasploit is an advanced open-source platform for developing, testing, and using exploit code. The extensible model through which payloads, encoders, no-op generators, and exploits can be integrated has made it possible to use the Metasploit Framework as an outlet for cutting-edge exploitation research. To the average user, one of the great mysteries of computing is how hackers and security researchers discover vulnerabilities in applications. There really are no special techniques needed to find vulnerabilities; it just takes a lot of experience and knowledge (http://sectools.org/sploits.html).
Metasploit was originally released as a research; however, Metasploit will certainly find use within the hacker community. Like other virus and worm “toolkits” circulating freely, Metasploit allows people with limited abilities to leverage the skills of others to create hostile code to exploit vulnerabilities in applications and operating systems, including all major Windows versions (http://sectools.org/sploits.html).
There’s no doubt that Metasploit makes it almost trivial to create hostile code. For security researchers and administrators, it’s undoubtedly a great way to proactively detect flaws in their applications and learn how to better defend networks against attacks. When it comes down to it, hackers already have this understanding. But tools such as Metasploit, while presenting the potential for abuse, also have the potential to teach–and empower the good guys with the knowledge the hackers already have.
This case study describes how H.D Moore and his Metasploit colleagues created an exploit of the now-patched Vector Markup Language, or VML, vulnerability in Internet Explorer. This exploit was undetected by 26 virus scanning engines, including those from Kaspersky, McAfee, Microsoft, and Symantec. Moore also created a zero-day exploit-one unleashed before there’s a known remedy to take advantage of vulnerability in Microsoft’s Windows Metafile. This prompted Microsoft to take the unusual step of releasing a patch five days ahead of its software-patch schedule. Even though Moore added to his prestige and forced Microsoft to fix its problem sooner, he also left Internet Explorer more vulnerable than if he’d worked discreetly with Microsoft (Greenemeir, 2006).
There are two ways to look at Moore and his team. They either give malicious hackers better ability to attack customers of Microsoft and other popular products; or they show tough love to software companies so they’ll produce more-secure products.
Netcat is one of the most commonly used anti-hacking tools. Netcat makes and accepts Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) connections. Netcat writes and reads data over those connections until they are closed. It provides a basic TCP/UDP networking subsystem that allows users to interact manually or via script with network applications and services on the application layer. It lets users see raw TCP and UDP data before it gets wrapped in the next highest layer such as File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), or Hypertext Transfer Protocol (HTTP) (http://technopedia.info/tech/2006/02/22/everything-you-need-to-know-about-netcat.html).
However, there is a gaping security hole in Netcat. This can make Netcat dangerous in the wrong hands.
This case study is about how hackers run Netcat. The evil attacker creates a copy of Netcat called iexplore.exe and runs a backdoor listening on TCP port 2222. Users or administrators searching for a malicious process would likely overlook this extra little goodie running on the box, as it looks completely reasonable. Giving a backdoor a name like iexplore.exe is pretty sneaky. However, an attacker could do something even worse by taking advantage of an interesting characteristic of Windows 2000, XP, and 2003. In these operating systems, the Task Manager won’t allow you to kill processes that have certain names. If a process is named winlogon.exe, lsass.exe, the system automatically assumes that it is a sensitive operating system process based solely on its name.
John The Ripper 1.0
John the Ripper 1.0 (JTR) is a free password-cracking program popular with hackers and security experts. The program was actually designed for the legitimate use of finding and cracking the feeble password with a view to improve the security of the system by entering a stronger password. But the program has found its place within the hacker’s world (http://sectools.org/sploits.html).
Provide JTR with an encrypted password file, and it will rip the file apart until it knows every password for every user on your network. JTR employs methods such as dictionary attacks, where it tries thousands of words from a wordlist in hopes of finding a match, or brute force, where it systematically experiments with millions of character combinations until it stumbles upon a password.
How do most professional hackers use John the Ripper (JTR)?
It depends on what they are trying to achieve. If they just want to prove a point JTR in single crack mode can reveal the weakest passwords in seconds and demonstrates the need for good password policy. Most use longer runs when they want to leverage the passwords they find to get deeper.
From what I read it seems that most use JTR mostly on Linux. They use it for both, a single password and groups of passwords cracking and typically don’t run it for more than a few days; however depending on how many hashes they get from a box is how many they run JTR on, and will continue to run it on a non production machine until the engagement is close to reporting.
It depends on what you are trying to achieve. If you just want to prove a point JTR in single crack mode can reveal the weakest passwords in seconds and demonstrates the need for good password policy. I use longer runs when I want to leverage the passwords I find to get deeper.
Are there ways to ensure the tools you are using are not hostile?
Only approved software should be operated on the organization’s network. This is so hostile programs cannot gain access to the network. Hostile programs may be written with some useful functionality, but may perform a hidden task that the user is not aware of. The ways to help determine whether a program is hostile include:
- Does the program come from a reliable source?
- Is there proof that the program came from the source such as a digital signature?
- If the source code is available for the program, the code may be checked to be sure there is no hostile content.
- A reliable third party may be able to check out the software and certify that it is safe.
- Does the creator of the program attempt to hide their identity? If the creator of the program attempts to hide their identity then there may be reason for suspicion. If the program creator does not hide their identity and can be reached, it is less likely that the program is a hostile program.
- Has this program been run by other people or organizations for some period of time with no adverse consequences?
Some of the above issues are not proof that a program is safe, but are merely indicators. Computer security is not an exact science and it is a matter of reducing the chance of an intrusion. Probably the best method of being sure of the reliability of a program is to allow a reliable third party to check the program. Program writers may even send source code to these service providers for certification with source code covered by a nondisclosure agreement.
What is the process of source code auditing?
Software vulnerabilities are a growing problem. Moreover, many of the mistakes leading to vulnerabilities are repeated often. Source code auditing tools could be a great help in identifying common mistakes, or in evaluating the security of software. The effectiveness of the auditing tools can be assessed by using the following criteria: number of false positives, false negatives by comparison to known vulnerabilities, and time required to validate the warnings related to vulnerabilities. In small and medium scale projects, the open source program Pscan can be useful in finding a mix of coding style issues that could potentially enable string format vulnerabilities, as well as actual vulnerabilities. The limitations of Pscan were more obvious in large-scale projects like OpenBSD, as more false positives occurred. Clearly, auditing source code for all vulnerabilities remains a time-consuming process, even with the help of the current tools, and more research is needed in identifying and avoiding other common mistakes. (2008, Heffley,Meunier). Auditing source code in an enterprise wide environment would be extremely time consuming.
What are the risks of using untested or exploited penetration tools?
Penetration testing can be an invaluable technique to any organization’s information security program. Basic white box penetration testing is often done as a fully automated inexpensive process. However, black box penetration testing is a labor intensive activity and requires expertise to minimize the risk to targeted systems. At a minimum, it may slow the organization’s networks response time due to network scanning and vulnerability scanning. The possibility exists that systems may be damaged in the course of penetration testing and may be rendered inoperable, even though the organization benefits in knowing that the system could have been rendered inoperable by an intruder. Although this risk is mitigated by the use of experienced penetration testers, it can never be fully eliminated (http://www.bankinfosecurity.com/html/webinar-penetration-testing.html)
Issues and Problems
The only issues with the lab had to do with the Linux virtual machine. On the Debian virtual machine, after installing so many packages like Xorg, fluxbox and the plugins to get Nessus to work, the drive ran out of space and mounted as read-only. As a workaround an Ubuntu virtual machine was created and had more space allocated.
In conclusion, this lab was very informative. It required the group to think more critically about tools that perform passive reconnaissance. The lab required that the group research passive tools, information pertaining to the timing of active tools and the relationship between those tools. The group discovered that if the tools take longer to run, they are less likely to be detected. When considering Nessus and Nmap, the group discovered that the data streams can be captured in order to passively obtain the vulnerabilities returned from Nessus. The research gathered helped the group answer questions pertaining to what this kind of attack means to attackers and security auditors alike. Finally, the group researched how security tools have, themselves, been vulnerable to attack. Also, the group discussed what risks are involved to enterprises when security-testing tools are not security tested.
“Crash Course: Open-Source Security Tools a Double-Edged Sword – Security – Network Computing.” Network Computing – Computer Networking, Network Security and Management. 26 June 2009 <http://www.networkcomputing.com/showitem.jhtml?docid=1712crash>.
“Everything you need to know about Netcat | Tech Pedia.” Technopedia. 26 June 2009 <http://technopedia.info/tech/2006/02/22/everything-you-need-to-know-about-netcat.html>.
Godefroid, P. (2007). Random Testing for Security:Blackbox vs. Whitebox Fuzzing. Paper presented at the Second International Workshop on Random Testing, Atlanta Georgia.
Greenemeier, Larry. “Is The Metasploit Hacking Tool Too Good? — IT Security And Hackers — InformationWeek.” InformationWeek | Business Technology News, Reviews and Blogs. 26 June 2009 <http://www.informationweek.com/news/infrastructure/management/showArticle.jhtml?articleID=193401125>.
Heffley, John, and Pascal Meunier. “Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security?” The IEEE Computer Society. 26 June 2009 <http://www2.computer.org/portal/web/csdl/doi/10.1109/HICSS.2004.1265654>.
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F10972%2F34577%2F01649124.pdf%3Fisnumber%3D34577%26prod%3DCNF%26arnumber%3D1649124%26arSt%3D%2B6%2Bpp.%26ared%3D%26arAuthor%3DParedes-Farrera%252C%2BM.%253B%2BFleury%252C%2BM.%253B%2BGhanbari%252C%2BM.&authDecision=-203 retrieved 6/27/09.
Jung, J. S., Anmol; Greenstein, Ben; Wetherall, David. (2008). Privacy Oracle: a System for Finding Application Leaks with Black Box Differential Testing.
“Making the Case for Penetration Testing.” Banking Information Security News, Regulations, White Papers, Webinars, & Education – BankInfoSecurity.com. 27 June 2009 <http://www.bankinfosecurity.com/html/webinar-penetration-testing.html>.
Tenable Network Security. (2009). Plugins. Retrieved June 27, 2009, from www.nessus.org: http://www.nessus.org/plugins/index.php?view=all
“Top 3 Vulnerability Exploitation Tools.” Top 100 Network Security Tools. 26 June 2009 <http://sectools.org/sploits.html>.