Interior Aspects of exploits...

Hey everyone, I'm going to try to word this thread the best I can. I have my own LAN setup here at home with boxes running Slack, SuSE, and XP. (irrelevant). But as I was, as far as exploits go and finding flaws in code, it is a subject I want to understand better, I will admit, I am just starting to learn to program with python, but I do have a pretty good background in network security, but never understood the inner workings of exploits. I am tempted to play with exploits on my system, but even though they are MY machines being tested on, Just the principle of it just seems Script Kiddie friendly if you know what I mean. Because I've always been the type of person when dealing with computers, wants to know what is happening, not just copying code into an editor. But the long drawn out point I am trying to make is do you guys recommend playing around with exploits on old boxes on my LAN for educational purposes, and in the near future will it help with programming skills ? Because don't get me wrong, I love patching systems against bugs, exploits etc. And I know what i'm patching against most of the time. For example if an update for SuSE is released for a race condition, I install it and go about my day, but it's just bothersome not 'really' knowing what I am protecting against. Please let me know if I am being too redundant.
Any good books, links ?

http://nob.cs.ucdavis.edu/~bishop/pa...-vulclass.html

Read that first... finding flaws in code is only a part of the problem, you also need to find a matching flaw in the policy... this is the part that so few people seem to understand.

A simple way to think about it is like this:

Sets:
1. (Use)
2. ---Code---
3. ---Policy---
4. (Successful Exploit)

Characteristics:
X = Normal
* = Exception

Example One: (trusted user/vulnerable code/correct policy/no exploit)
1. XXXX
2. XX*X
3. XX*X
4. XXXX

Example two: (malicious user/vulnerable code/correct policy/no exploit)
1. X*XX
2. X*XX
3. XXXX
4. XXXX

Example three: (malicious user/vulnerable code/flawed policy (no overlap)/no exploit)
1. X*XX
2. XX*X
3. X*XX
4. XXXX

Example four: (malicious user, vulnerable code/flawed policy (overlap)/EXPLOIT)
1. X*XX
2. X*XX
3. X*XX
4. X*XX

Hopefully this will help you understand the nature of exploits a little better.

cheers,

catch

I am the same way, always desiring to understand exactly what is going on in the underlying code, rather than doing the copy/paste routine (I think this is one thing that begins to seperate the skiddies from true geeks).

I have found it extremely helpful to have a test envirnment set up to run 'sploits against. I have also found it helpful to attempt to tweak the code to see what happens. One thing that will help you a lot if you are focusing on exploit code is to learn the machine code that is behind a lot of the exploits...I'm still working on that part.

This process has definitely helped me with my program skills...the more code you get your eyes into, the more you will learn. I can now walk through code and "see" exactly what it is going to do, which is a necessity for a programmer. I'm still a noob, but I'm learning....dig in, and you will too.

I personally think that anyone who looks beond the exploit its self is more then a skiddie. I mean if you just take it compile and run it, What do you know about it? its just a weapon or a big shiney button that gives you root. A lot of people take them as just that. I myself and I'm sure a number of people want to know how and why. I think that is the real way not to be labled a script kiddie. Oh also and not using them for harm. Personaly I feel that you should examin boath sides of computer security and not have just a defencive stance. Also try to do this in a controlled, safe, and legal compound.

If thats the way you think you can learn best then go ahead - personnally I agree and I'm trying to go down the same track (or as I say moving up the stack). May I recommend several tools to assist in following the process and books you may find useful:
(some of these may be viewed as more windows related)

tcpview - open ports and processes
process explorer - super task manager
ollydbg - assembly level debugger
windbg - debugger (obviously best for windows apps and dump reads)
tdimon - ports and packet activity
regmon - register calls and changes
filemon - file calls and changes
Ethereal - tcp/ip packet capture
Nessus (or similar vulnerability scanner)
Nmap - port scanner
snort - intrusion detection
Visual Compare - compare two files, captures etc
dependency walker - module calls

Books - The Shellcoders handbook, Reversing - secrets of reverse engineering and Malware - fighting malicious code (my apologizes for not naming the authors or ISBN numbers)

"freecommandlinetools" - Borland C++ compiler (or something similar for whatever programming language you prefer)

I think these tools cover all the layers and the paths an exploit can travel to the final destination - agreeing with catch's methodology (don't just look at the end result). You can see the IDS alert, read the raw packet trace, see the port activity and move up from there.

May I suggest when beginning to debug that you use a simple app and simply capture and compare a good login vs. a bad login.


Alot of work but it is alot of fun