Ask HN: How do you learn to develop exploits?

Depends on what you are trying to exploit I imagine, there are a huge number of different techniques out there.

Have a look at http://www.securityfocus.com/archive/1

and if you can get some sample exploit code and study it.

Then perhaps study some of your own programs with a more devious mindset and figure out what you have forgotten to take into account.

yes, 2600 still exists. I buy it sometimes.It's good stuff.

I'm not sure about recent versions but the first edition of "Hacking: The Art of Exploitation" was great a few years ago.

The best way is to start from the beginning, in other words read "Smashing the stack for fun and profit". These technics doesn't work on current operating systems but gives to a great start http://insecure.org/stf/smashstack.html

Read as much as you can about assembly. Debuggers are your best friend. Pick a target (app, iPhone, xbox, whatever). Attach debugger and step through the code and learn possible entry vectors (buffer overflow, loading for arbitrary file i.e. pdfs, so forth). Once you have an entry vector you essentially have an exploit, the rest is developing that exploit to do something "useful".

Sorry for the shortness of this response, if people are interested I can throw together a couple of blog posts.

tptacek (of Matasano) has a list of books on Amazon he has suggested for learning just that: http://www.amazon.com/lm/R2EN4JTQOCHNBA

Fravia's portal on reverse engineering used to be a great starting point. Starting with Assembly and (old) Phrack articles as others have suggested is a great idea as well.

Maybe a fun way to get started would be taking an old version of a shitty server of some service and try to find possible ways of breaking it by examining the source code. There are really thousands of assumptions each computer program makes about the external world and security research seems to work by giving those assumptions an examination much closer than the original programmers gave.

In the end I don't think there is too much to say about "exploit development" per se, it's all about identifying those assumptions that could be fruitfully abused, once you find a way, writing the exploit should be the easy part. So, I would take some amateur ftp server, or maybe something famous for its insecurity (I know wuftpd used to have a bad rep) and then basically try writing a FTP client that tries to break some restriction the server or protocol intended to keep. From there, you just have to learn to identify more assumptions, by studying programming languages, operating systems, network protocols etc., whatever might be helpful (and it always amazes me what kinds of crazy details people in security can take advantage of). Another aspect is exploring the assumptions of software you don't have the source code of, so basically reverse engineering.

I am more of an admirer of security work than a practitioner, so maybe other people can elaborate some more, but I hope this is a valuable starting point.

I've got http://exploit-exercises.com/ bookmarked, but haven't had a chance to start the exercises yet.

Ideally you have to master a low level language like C, socket programming and assembly on various architectures. You can somehow get away with a scripting language like perl or python and drop-in shellcodes but I suggest you do it the hard way.

You can start reading the classics (although most of them not applicable today) like Smashing the Stack for fun and profit by Aleph One, 7350 (teso security group) papers on format-string exploitations as well as various other techniques on heap-over flow techniques, double free()'s etc. A very good book for all round exploitation with some advanced techniques is "The Shellcoders Handbook" which I highly recommend. The Phrack magazine (before the editing team changed) has some really juicy techniques on exploiting various platforms.

Other than that, you should browse through A LOT of source code trying to identify bugs in open source software and subscribe to various security bulletins so you can read advisories and try to exploit them. GDB is your best friend for that job since analyzing core files is the beginning of everything.

Finally you should get involved in security communities (the more under the ground they are, the better) and attend security cons (HAL, Defcon, CCC).

I used to do some heavy exploit writing back in high-school and I can tell you it's really REALLY fun but time-consuming and frustrating sometimes. Exploiting software is a form of puzzle solving.

"Smashing the stack for fun and profit" is absolutely a great introduction to the classic buffer overflow attack. It is also the foundation on which tons of exploits are built on: http://insecure.org/stf/smashstack.html

Once you've read that, I highly recommend going through Stanford's CS 155 practice assignment on the subject. Unfortunately I really can't find the assignment anymore but perhaps a more thorough search of their archives would reveal it.

However, here is a blog which details the answers to all of the problems and includes the problem themselves. It explains why they work, and how to get to them. Very helpful if you are interested in looking at more advanced techniques: http://blogs.hulmahan.com.ph/archives/category/hack-101

That takes care of the basic C sploits. Beyond that, it really depends which level you want to attack at. You can attack at the stack level for almost all programs.

For web applications, you can go at a much higher level with stuff like SQL Injection, Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and Session Hijacking.

Lastly, I highly recommend "Grey Hat Hacking, The Ethical Hacker's Handbook." This book does a fantastic job of giving you a taste of hacking at all levels. It covers OS attack possibilities, network level attacks, exploit generation and more. It also does a great job of introducing you to a lot of tools that help get the job done. From there, you'll at least be able to think of what you want to learn about next.

I would argue the magazines (such as 2600, which I absolutely loved when I was young) and books and oral tradition are all just ways of passing around specific and awesome anecdotes: it doesn't teach you how to do that, it is just interesting facts or entertainment for people who know.

What you need, instead, is a mindset: when you are at the supermarket checking out with one of those self-checkout machines, does some part of your brain start figuring out mistakes made in the mechanism that might allow someone to steal items?

If not, that is the kind of thought process that you need to get yourself to start doing: you need to keep asking yourself "if I were evil, could I do something evil here?", and you need to make it fun enough that you are doing it constantly.

With this mindset, finding exploits in software just becomes "teach me to program", as the kind of devious backchatter in your brain will just see things popping out "wait, what's to keep someone from cheating here and doing the opposite of what you say?".

The really epic hacks then just come from many years (the stereotypical 10,000 hours) of experience programming and trying things: it isn't because they read some magazine or learned from someone else. Instead, their midset just got better.

Think of it this way: it makes a lot of sense to ask "how do I learn how to use a violin", but "how do I learn musical taste" and "how do I learn to hear music in everything that surrounds me" are more awkward. The former is a skill, the latter two are mindsets.

Two things: understanding and manipulating.

1. Understand what a program is. How the architecture of your computer allows it to run programs. How to look into the guts of a program - currently running or while dormant - and figure out how it processes any and all input you are able to feed it. What mechanisms are in place to prevent exploits.

2. Study bug classes and exploitation techniques. Information leaks are often important to remotely exploit code protected by ASLR. Build fuzzers. Use a tool like the absolutely incredible Vivisect recently released by visi at SummerCon a few days ago to see whether it is possible to get to a vulnerable code segment from the entry points you are able to find. Craft input to reach the identified bug, and leverage it to achieve arbitrary code execution. Never forget that while your focus may be zoomed in on a handful of opcodes that there is in fact an entire system environment in place and potentially at your disposal.

It's a daunting amount of information. Many of the best have been taught via something reminiscent of oral tradition, and like anything you wish to achieve mastery of you will learn faster with feedback from those with more experience. Most public hacker forums are about downloading tools for SQLi and have nothing to do with exploit development at all. But make some friends who are good at it and seek their feedback.

I guess start off by reading the corelan exploit tutorials, which go pretty deep pretty fast and may be a good start for somebody with programming experience. Simultaneously work through the reversing tutorial by lena on tuts4u. I think that may be a good start.

Look at "Insecure Programming by example": http://community.coresecurity.com/~gera/InsecureProgramming/

Here's my suggestion

You create a toy exploitable program, and you start exploiting that

But before that, brush up on C and assembly (the basics of assembly at least). x86 is "easier" (more human readable I'd say but lots of quirks if you want to write, but easier than x86 in 16bit) but if you want to study exploits in other platforms they have some quirks.

That's "exploits 101" lets's say. That will cover the most basic tools you'll need and trying that is a great exercise

See the links other posted for "smashing the stack for fun and profit"

After that, you could try old programs and studying known exploits for specific versions (say program X has a certain exploit that works like that, so you could try making an exploit for that)

A lot of it is an understanding of human behavior, right? Especially one of other programmers. I once had to find a file that a company was compelled to publish but then replaced with a different version after a certain time period. The company said that this was legally fine but rather than argue about it, I just looked at the source code and saw that the href of the currently published file had "2" appended to it, as in, "list2.xml"

I knew from past experience that the company had hired someone to basically just make a separate site to host the damn file...in other words, the PR department had minimal knowledge/care about the technical details of the website.

And knowing how contract developers worked...that is, they know that if their client no longer sees a visible link to a file, than that file has been "deleted"...I just tried something like "list1.xml"...and voila

I know buffer overflow hacks are incredibly interesting but how many of the most significant hacks have been done through plain out guessing the target? I don't even mean social engineering...take, for example, the update_attributes hack on Github's rails setup. The vulnerability was well known and dismissed., so the hacker guessed how a project team might slip up and perpetuated an amazing and thankfully benign hack.

So I guess, a good start is to just be a decent programmer yourself, and to have understood why you follow the best practices

http://exploit-exercises.com/ has a good virtual machine that you can exploit in your own time. I enjoyed working through Nebula.

You may have fun building fuzzers. You just feed all kinds of varied, random data to your app. If you only expect numbers, try and see how your app behaves if you feed it large or negative numbers, strings in certain charsets.

You'd be surprised to see the amount of apps that accept a single non-breaking space (alt + 0160) as an username.

Don't assume that a disabled, unchecked checkbox in a registration form can't be enabled/checked. Don't expect that you'll receive a value from a <select> element that is actually contained within that dropdown's options.

When your app breaks horribly, your curiosity will hopefully throw you into a night of reading and hacking.

You can read more about fuzzing at Jesse Ruderman's blog[1]. He wrote very interesting fuzzers for Mozilla's JS, DOM and CSS parsers.

Sometimes, a friend of mine would ask me to check out his project. I proceed to act like an incredibly malicious user, then have this friend get mad at me.

It all clears out after explaining that he would always run into someone trying to break things. Even someone just trying to get a laugh!

[1] http://www.squarefree.com/categories/fuzzing/

Try these out:

"keygen" sort of thing (reversing):

writeup: https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f..., tarball: https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...

Exploiting a variety of buffer overflows:

writeup: https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f..., tarball: https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...

For in depth technical work, try doing "crackme" puzzles. Google for them and you'll find some. Also, take a look at fravia's pages (I wonder if he's still alive?)

Edit: http://www.woodmann.com/fravia/

I see a few other people have already recommended resources for learning about vulnerability discovery, which is mainly about fuzzers these days. A good resource for determining how to exploit that vulnerability so that it does neat things for you is The Shellcoder's Handbook (some asm required, but not too hard if you know some OS internals).

There's a lot of good advice here. I'll limit this post to how I learnt. I'd never really read any articles before starting out on my own. For me it was mainly curiosity. I was writing code with a bunch of guys at school, and one of the guys wanted to protect his data (on a shared data store), so he implemented his own encryption scheme. I didn't know anything about encryption, but had access to his source code, so studied his algorithm and managed to build a decoder.

After that I started studying my own programs to see if there were any obvious patterns that someone else could guess. This was before the days of CGI on the web.

My curiosity continued when CGI was growing and I learnt first how to fool a guest counter, and then how to build a more secure one. I started learning peel and read all the man pages. There was a lot of stuff in there that was like "don't do this because it's insecure". To that end I owe a lot to Larry, Randall, and Tom.

What I learnt from there helped me protect myself against XSS attacks, but also taught me what to look for without needing the source. It wa a while before I heard about CSRF attacks. At this point I was interested enough to see what OWASP listed as the top exploits and did some studies on each of them.

At no point have I ever used what I know for malicious purposes.

The way most folks learn to do high end niche programming: In advanced degree programs, research organizations and through professional development at government employers / contractors.

Charlie Miller is a well known example of this - he famously markets himself as a reliable exploit writer, his background came from doing the same work at the NSA.

In most cases it's a very technically challenging effort, beyond what most people will self teach. Simply finding the bug is often the easy part as compared to reliable exploitation.

The best publicly accessible sources of learning are security conference papers and university theses, though they don't usually explain the basic techniques or high level techniques. "Underground" sources like 2600 for the most part publish rather poor or incomplete material, though they occasionally do have some top notch stuff.

I assume this is related to the old Andy Greenberg article that's on HN right now. While I wouldn't say those prices are an outright fabrication, it is definitely misleading. It is very rare for those kind of prices to get paid, at least reliably. It's much more common for prices to be in the four or low five figures ranges when sold and often go completely unsold. It has a lot to do with who the buyer is and what their budgets are like and how well known you are and on and on - not totally unlike a traditional governmental procurement process.

What that article really was was an advertisement for that broker - the price list was there because he's trying to say hey you're getting screwed come to me! I would guess that the reality of working with him is significantly more middle class.