Art of Exploit Writing and Penetration Testing
Hi friends, I wanna share my views on one of the favorite topic "Art of Exploit Writing and Penetration Testing " first of all lets define "Exploits",as "A tool developed by hackers that is used to perform malicious attacks on computer systems. They are usually scripts that are designed to exploit weaknessness in software over a network, most commonly the Internet. Zero-Day is a common type of exploit."
And "Penetration Testing" can be defined as, "A penetration test, occasionally pentest, is a method of evaluating the security of a computer system or network by simulating an attack from a malicious source, known as a Black Hat Hacker, or Cracker. The process involves an active analysis of the system for any potential vulnerabilities that could result from poor or improper system configuration, both known and unknown hardware or software flaws, or operational weaknesses in process or technical countermeasures."
Make the Exploit Stable
It is a good idea to ask yourself a series of questions once you’ve got the exploit working, so that you can determine whether you need to keep working to make it more stable. Although for some readers it may be enough to be able to point at a single working example of an exploit, if you’re actually going to use it in a production environment, you should be aiming for industrial- strength exploits that will work anywhere and won’t change the target host in any undesirable ways. This is a good idea in general, but also helps cut over all development time; if you do a good job the first time, you won’t have to keep revising your exploit every time a problem occurs.
Here is a quick list, you might want to add more of your own questions:
- Can you run your exploit against a host more than once?
- If you script your exploit and repeatedly run it against a single host, does it fail at some point? Why?
- Can you run multiple copies of your exploit against a host simultaneously?
- If you have a Windows exploit, does it work across all service packs of the target OS?
- Does it work across other Windows OSes? NT/2000/XP/2003?
- If you have a Linux exploit, does it work across multiple distributions? Without needing to specify offsets/versions
- If you require users to enter a set of offsets in order for your exploit to work, consider hard coding a set of common platform offsets in your exploit and allowing the user to select based on a friendly name. Even better, use a technique that makes the exploit more platform independent, such as deriving the addresses of Load Library and Get Proc Address from the PE header in Windows, or not relying on distribution-specific behaviours in Linux.
- What happens if the target host has a well-configured firewall script?
- Does your exploit hang the target daemon if IP Tables or (on Windows) an IPSec filter rule set blocks the connection?
- What logs does it leave, and how can you clean them up?
Methodology behind Exploit writing and Penetration Testing: -
Sometimes security researchers can get lucky when auditing an application without following any concrete plan. They might just happen to read the right piece of code at the right time and see something that has gone unnoticed before. If however, your goal is to find a definite vulnerability in a particular application or to attempt to find all bugs in one application (as is the case in any professional source code audit), then a more well-defined methodology is needed. What that methodology turns out to be depends on your goals and the types of vulnerabilities you are looking for. Some possible ways to audit source code are outlined here. Vulnerability research can sometimes be a frustrating task, but at other times it is a lot of fun. As an auditor, you will be searching for something that may not actually exist; you must have great determination in order to find anything worthwhile. Luck can help, of course, but consistent vulnerability research usually means hours of pain staking auditing and documentation. Time has proven repeatedly that every major software package has exploitable security vulnerabilities. Enjoy auditing : D
The idea behind our approach is to simplify the researcher’s view of the system, allowing him or her to focus on the structure and behaviour of the system from a technical security perspective rather than being led along some predefined path by vendor documentation or source code. It is more of an attitude and an approach than a specific technique, although you will need some basic skills. Our experience has been that this approach leads to the discovery of bugs that were “not thought possible” by the development teams —because they were too obvious, or obscured by the source code (for example, complex C macro definitions), or because an interaction between components of the system had simply not been thought about. Throwing away the rulebook, so to speak, is a liberating thing.
The approach can best be summarized as follows:
- Attempt to understand the system without referencing its documentation and source code.
- Investigate likely areas of weakness. During the investigation, make use of system tracing tools to learn more about the behavior of the system and take note of where behaviours diverge—these points may not be obvious.
- Where differing behaviors are observed, attempt common forms of attack and observe the response.\
- Continue until you've covered all the behaviors. Perhaps a concrete example would clarify the process.
The process of discovering vulnerabilities can be time consuming and extremely tedious. We can save time and increase our efficiency by developing and maintaining a toolkit specifically designed to discover flaws in targeted software packages. This toolkit should consist of utilities and technologies that will allow us to audit an application’s source code and its compiled machine code. We should also include tools that allow us to audit an application while it is operating. This category of tools includes aggressive auditing technologies such as fuzzers or etc, as well as miscellaneous passive monitoring tools. Each of our tools allows us to examine the security of an application from a different perspective. The technology within each of our tools has its benefits as well as its weaknesses. By combining several of these technologies, we can eliminate many of their weaknesses while retaining their individual strengths.
The content on Hacking Beast like Hacking Articles, Cyber News etc are provided by many sources ( email,messages,internet etc) , we do not take any responsibility of your activities. The news provided by us on this site is gathered from various sources. if any person have some FAQ's in their mind they can Contact Us. and you can also read our Disclamier for more info. Thank You !
If you enjoyed Hacking Beast Articles , Make sure you subscribe to our RSS feed. Stay Updated about latest Hacking News, Tips and Tricks,and Cyber News.! and recieve all our emails and latest posts directly in your inbox to enjoy fast and easy reading . Thank You!