Objectives:
- Students will examine a variety of methods to exploit target systems.
- Students will implement exploits based on analysis of systems
- Students will determine the likely existence of unknown exploits and target them
- Students will determine a course of action in dealing with exploits.
- Students will evaluate the exploit hierarchy.
Deprecated
- Students will create a stand-alone exploit
- Students will examine exploit methods and create a new exploit.
- Students will test their exploits within the laboratory environment for effectiveness.
- Students will examine the ethical issues and discuss them in depth.
Directions:
Part 1
Researching exploits is kind of like researching air. It is all around you, you operate within it, need it, but rarely notice it. Exploits are kind of like that. It is much easier if you describe the environment a little closer so you have a framework. For this laboratory section you will be investigating exploits that possibly could work against your systems and methods of testing for those exploits. Take the NESSUS or NMAP applications (your choice) and figure out using the OSI 7 Layer grid all of the exploits from the chosen tool that will work against your systems. Now I will tell you. There is an easy way to do this, and a hard way to do this. Your choice.
1) Research the load of exploits and types of exploits using the same grid and information methodology from laboratory 1 found in your copy of NESSUS/NMAP.
2) By system list the exploits that would work or could work.
3) Find the stand-alone tools that will work with the NESSUS/NMAP exploits.
4) Verify through testing that the stand alone tools work against the target systems.
5) Explain how you came to these conclusions and provide summary evidence.
6) Write up the strategy used to gain this knowledge.
7) Test to see if they actually work, and provide summary evidence of that.
Part 2
Exploits are published on a daily basis in many places. BugTraq by Security Focus is a good example. Find other sources (no less than 4) that publish this kind of information. One hindrance you will run up against is the fact that there are pay for services that provide this information. Do NOT spend money on this. Open source information repositories should provide the information easy enough. Vendor specific sources only count as 1/3rd so you’ll need three of them to make 1 of your minimum four total.
1) Research exploit code and data repositories (no virus vendors!!!)
2) Research and provide evaluation of the level of expertise involved.
3) Audit and analyze the exploits using the grid model from laboratory 1 and the OSI 7 Layer model. Are there any interesting conclusions you can make?
4) For any conclusions provide a statistical robust sample to prove your case.
Part 3 (NOT REQUIRED SUMMER 2009)
Research exploits that other people have done is the lowest level of penetration testing possible. As such researching exploits should include looking for unknown vulnerabilities that you can exploit by awareness of the system. Taking one system evaluate by analysis what areas have not been exploited, engineer an exploit for that vulnerability, and test the exploit.
1) After having evaluated NESSUS/NMAP scans you know of possible vulnerabilities. You can plug those into the previously mentioned grid and find where holes are.
2) One issue is what has been patched or not patched. If NESSUS/NMAP doesn’t show a particular vulnerability then can be somewhat assured (though not sure) knowns (not all) in that space likely have been patched.
3) Now the next level above script kiddie (using others code) is to piggyback on a known vulnerability and create a new tool that exploits a known issue. The Metasploit framework allows this to be done easy.
a. Research how to plug exploit code into Metasploit.
b. Write a Metasploit exploit code segment.
c. Import it into the tool and test.
4) The next level above is to write your own tool or exploit the artistic equivalent of freehand. In other words without using something like the Metasploit framework.
5) Just doing the same exploit as previous though is not hard.
6) Look at the grid where there is no currently listed exploit. Supposedly these areas are already secure. Supposedly.
7) Write an exploit without using Metasploit or piggybacking on a known exploit. This will require a lot of research.
8) How to do this?
a. Frame the possible known exploits for a given OSI 7 Layer model. Use other operating systems as possible idea donors.
b. Frame the possible strategy for writing a tool to exploit that layer.
c. Run tests against your zombie machine until it works.
d. Expect it to take a lot of time.
e. Do not publish results of this in a public arena without instructor permission.
9) What are the ethical issues with telling the world about this without telling the OEM?
Special Directions:
Follow the directions in the syllabus.
If using the Citrix systems and you need a reset expect 24-48 hours turn around on those requests there is also the chance of weekend outages.
