EH-Net

Hi all, i want to ask something about writing exploits:
  - What i need to write my own exploits ?
  - about language, sometimes i'm rather confused about what language i
    must use to write exploits or it depends on what exploit i want to make ?
I'm very need advices and criticsm about this thing.  :)
Thank's alot and sorry for this stupid question.  :)

I suggest you looking into Writing Security Tools and Exploits (http://www.amazon.com/Writing-Security-Tools-Exploits-Foster/dp/1597499978/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221468458&sr=1-1).

I'd highly recommend learning a flexible scripting language like Perl or Python.  I've not learned python myself, but I've found knowledge of Perl to be invaluable at times when you want to do some quick automated task, (such as taking the tedium out of blind SQL injection for example).

seeing as maybe you're wanting to write your own tools, you should also learn C - it's not hard to pick up and is quite powerful as it is a low level language and will teach you quite a lot about the intimate details of how a machine runs. 

if you give us a bit more detail about where you're comming from and how much experience you have and in what areas we may be able to direct you more specifically.

Learn perl, python. And master C and assembly. Some of the people here will not agree with C and assembly thing but believe me, you should consider learning them if you are really serious.

If you want to write buffer overflow exploits, you need to learn C and assembly.

The standard introductions to buffer overflows are:

• Smashing the Stack for Fun and Profit
  http://www.phrack.com/issues.html?issue=49&id=14&mode=txt
• How to Write Buffer Overflows
  http://insecure.org/stf/mudge_buffer_overflow_tutorial.html

Once you've mastered this, you can move onto advanced techniques.  Read the papers in the list below and follow the references as they suits your interests.  Setup a Linux or FreeBSD box with no buffer overflow protection (No non-exec stack, PaX, W^X, etc, ProPolice, etc) so that you can practice.  I used FreeBSD 4.x and 5.x when I did most of this.  As you get into the material about defeating the different protection mechanisms, install ProPolice on BSD or non-exec/Stackguard on Linux.  Can you get around them?  It's good to understand PaX (which was eventually discovered to have a major flaw) and W^X, but you don't need to worry too much about defeating them in the wild.  You're more likely to encounter stack based protection such as Stackguard or Microsoft's /GS, a non-executable stack, and/or stack randomization.  It will take you months to read all of these papers and to practice using at least some of the techniques, but if you can get through them all you will have some real expertise in exploiting buffer overflows. 

Be sure to read the Bugtraq list.  Look at the exploits that are posted and try to understand what they do.  Good luck.

Metasploit can be helpful in creating exploits and shellcode, but I think you'll learn more by doing things yourself.  That said, there is nothing wrong with using it to speed things up once you master the basics of writing exploits and creating shellcode.

Good luck.

• w00w00 on Heap Overflows
  http://www.w00w00.org/files/articles/heaptut.txt
• Taking Advantage of Non-terminated Adjacent Memory Spaces
  http://www.phrack.com/issues.html?issue=56&id=15&mode=txt
• The Frame Pointer Overwrite
  http://www.phrack.com/issues.html?issue=55&id=8&mode=txt
• Bypassing Stackguard and Stackshield
  http://www.phrack.com/issues.html?issue=56&id=5&mode=txt
• Defeating Compiler-level Buffer Overflow Protection
  http://www.usenix.org/publications/login/2005-06/pdfs/alexander0506.pdf
• Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server
  http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
• Getting around non-executable stack (and fix)
  http://seclists.org/bugtraq/1997/Aug/0063.html
• Basic Integer Overflows
  http://www.phrack.com/issues.html?issue=60&id=10&mode=txt
• Exploiting Format String Vulnerabilities
  http://doc.bughunter.net/format-string/exploit-fs.html
  http://julianor.tripod.com/bc/formatstring-1.2.pdf
• More info on format bugs
  http://julianor.tripod.com/bc/kalou-formats.txt
• Defeating Solar Designer's Non-executable Stack Patch
  http://insecure.org/sploits/non-executable.stack.problems.html
• Advanced return-into-lib(c) exploits: PaX case study
  http://freeworld.thc.org/root/docs/exploit_writing/p58-0x04.txt
• Bypassing PaX ASLR Protection
  http://www.phrack.com/issues.html?issue=59&id=9&mode=txt
• Vudo Malloc
  http://www.phrack.com/issues.html?issue=57&id=8&mode=txt
• Once upona  free()
  http://www.phrack.com/issues.html?issue=57&id=9&mode=txt
• Overwriting the .dtors section
  http://synnergy.net/downloads/papers/dtors.txt
• _atexit in Memory Bugs
  http://doc.bughunter.net/buffer-overflow/atexit.html

Nice post and a very handy list :)

Thanks

I've been playing a lot of CTF lately, and two books have really helped.  Hacking, the art of exploitation (http://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441 (http://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441)) is the first, and The Shellcoder's Handbook(http://www.amazon.com/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/047008023X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221526745&sr=1-1 (http://www.amazon.com/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/047008023X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221526745&sr=1-1)) is the second. 

You are going to want to know some assembly along the way, they will help you some, but find a good assembly book.  You will also want to know some programming language, I would probably learn C and perl or python.  I personally prefer perl, but I think it's one of those pancake vs waffles things, they are both delicious.

Thank's a lot guys for all of your advices, i'll deep learning on my c programming cause i never touch c programming for 1 year and because of that i must repeat my c again  :P
Thank you so much guys.  :)

On the other hand...

If you want to learn about web application exploits knowning C, Perl, and all about memory addressing won't be of very much use (exploiting a C based CGI web application or Perl web application aside).  In order to exploit an application you have to understand the technologies on which it rests.  Web application technology usually relies on a scripting language (PHP, ASP, JSP, etc.), and a database (MS-SQL, Oracle, MySQL). 

That said, I'd like to cite a recent blog post from SecurityBuddah.com (http://securitybuddha.com/2008/09/10/are-you-a-builder-or-a-breaker/ (http://securitybuddha.com/2008/09/10/are-you-a-builder-or-a-breaker/)).  The point of the post is to ask why so many people in security focus on breaking things rather than building better software.  I think learning to actually program in a language will be a much more valuable endeavor if you really want to learn to write exploits.  Being able to create an application, securely, teaches you much more about the pitfalls of application security than simply learning to write exploits.  The most skilled penetration testers can pull apart a target by analyzing services and software based on their own knowledge of how to build such things, and common points of weakness.  Knowing how to build apps allows you to do actual code level audit of systems, which is more thorough and likely to catch subtle bugs that automated testing will miss.  Sure, it takes a lot longer to learn to build applications and systems than it does to simply break them, but the value is much greater.  Why not learn how to spot weaknesses and offer fixes instead of just how to break things?

If you want to be a professional "breaker" then you are going to need to learn why the things happen that you can break.  So many of the technologies today are easy to break and harder to fix, especially on the web.  Unless you have the knowledge to be able to explains what went wrong people will see you much more as a script-kiddie than a knowledgeable professional.  Finding XSS exploits is pretty easy in many occasions, talking to the folks who have the vulnerable application and explaining strategic solutions to fix their problem as well as what lead to the problem is where the money is at.   

On a separate note, in my opinion, learning a scripting languages will probably help you with just about any type of exploit unless everything you do is through a GUI.  For the stuff that I have written for exploiting C applications, most of the code I've written has been in perl and when I'm doing web based assessments that are beyond the basics, I frequently pop back to perl or python to generate the code that I'm going to use for exploit.  Plus, putting your exploit in a script means that it's useful to others, and unless you don't plan on showing anyone else what you did or ever doing it again yourself it's nice to have it especially if you either added a comment here or there or used logical variable names.

Final thought on the breaker vs maker since I've been on both sides is that in many cases, and I encounter this all the time, people don't really understand the magnitude or impact of what they are doing until you show them how it's bad.  I think it's kind of analogous to when you're a kid and a parent says "don't touch that, it's hot" and sure enough, you figure it out on your own.  In some ways, unless we can show what can happen in a controlled environment then you may not get the response that you want.  I think that this is especially true with problems that don't yield a shell on a box.  So much many applications have  XSS bugs in them these days.  When you explain it to someone and they simplify it as "so someone can click on a link and have some other stuff show up  on the page?" then it really doesn't sound that scary.  When you show them that when they clicked on the link for what they thought was the latest Peggle download from their web based email client, that you stole their session cookie and now have full access to their email, then that has a little bit more impact.  I won't say that is necessary all of the time, but it is something that I run up against.

Yes, well stated Apollo.