Ask HN: How do you learn to develop exploits? | Hacker News Reader

Ask HN: How do you learn to develop exploits?

166 pointsbcattle78 comments

Too few people in the world understand technology. Of those, the vast majority don't do anything creative with it. I would put myself in this category. A few people are extraordinarily creative and come up with the exploits we read about in the news.

Let's say you're a competent programmer with minimal prior exposure to security. What should you read/do to learn how to see and engineer these kinds of exploits? I don't want to be Picasso, I just want to learn how to paint so I understand how he does it.

For the record, I'd say a working hands-on knowledge of this should inform the design of any system.

Is it a person-to-person oral tradition? Is it on some private message boards somewhere? Text files? There used to be 2600 Magazine, does anyone still read that?

Maybe it's all of the above. Where is the best place for somebody smart to start reading/inspecting/programming and quickly learn what matters?

View on HN

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.

I had an opportunity once to sit down with Don Knuth and play Halo on the X-box. Don was doing really poorly and I said, "Don, what are you doing?" His answer was "Playing."

But for Don, playing wasn't kill the bad guys, get the best weapon upgrade, it was "What happens if I just sit here when this NPC wants me to follow him?", "Can I jump off this ledge in the back even though the game doesn't think I should?" He was playing not the game of Halo but the game of Halo Exploits! Once I realized what he was doing we started a variety of different tactics to see if we could break the game. We found several in a fairly short period of time. One where you could get 'behind' the geometry of the space ship you were on, run all the way to the other side where the big bad guy for the level was, and shoot him dead up through the floor without him being able to fight back. It was quite fun.

There is a story about a physics student given a word problem of finding the height of a building using a barometer. Since they couldn't remember the perfect gas law they instead drop the barometer from the roof and time how long it takes to smash into the ground below. Then compute the height that way. It that kind of thinking that people use to find exploits. That, time, and sometimes browsing the source code.

Doing security code reviews is also good training.

> There is a story about a physics student given a word problem of finding the height of a building using a barometer.

If memory serves me right, Bohr was the student and Rutherford was the arbitrator?

Edit: Legend according to snopes (http://www.snopes.com/college/exam/barometer.asp)

Wow, that must have been awesome. Thanks for sharing!

"I had an opportunity once to sit down with Don Knuth and play Halo on the X-box." ... best thing I will read today.

I think finding holes can be a matter of developing dry, ironic sense of humor.

A hole is more or less a bug that can pushed a bit further. It has a lot of similarities to a joke. You thought your code "meant" X but really it "means" Y. SQL injection is a way of "saying" something that your "audience" wasn't quite expecting. It's a lot the jokes that start "he put the frozen turkey in the back of his truck and drove off ... and then ... and then" with lots of unexpected results.

My totally non-expert opinion is that if you practice finding this stuff amusing, you'll see more and more of it.

Specifically with code, you have to learn how to see it in a more abstract way. Not just a sequence of instructions, but a function that operates on a space of inputs, some good, some bad. Almost like a quantum superposition of all possible inputs, and which outputs those generate.

There is a great interactive article on this by Bret Victor: http://worrydream.com/LadderOfAbstraction/

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.

I would be interested in seeing some of those blogs

+1 for the blog posts.

"I will write blog posts if people support this notion."

"I support you writing blog posts on this matter."

Downvotes ensue.... Seriously?

Doesn't upvoting the original comment suffice?

Do people really need to also write out their support?

That would be really nice. I actually started learning programming so I could become a better "h4x0r" (I was a kid). But then I discovered I liked making things a lot more. I'd be really fun to go back and learn the things that inspired me to play with a computer in the first place.

For some (old, out of date) information you could have a look at Fravia's information.

(http://www.woodmann.com/fravia/)

This is ancient; and Fravia is dead, so updates are unlikely. Fravia was also Italian and the writing is, uh, sometimes hard to follow. But I include it because it gives insight to the frame of mind that is needed, and is comprehensive about the tools that used to be used.

(http://en.wikipedia.org/wiki/Fravia)

Someone putting together some blog posts for HN would be very much appreciated.

Aahhh... Fravia and the "crackstore" were great places to get tuts about hacking/cracking in their time (e.g. tKC tuts where good to follow as a kid).

I still miss those days of SoftIce :). Good memories.

Anyone else frequent http://freaky.staticusers.net/ back in the day? I always found their forums full of goodies [esp if you were interested in hacking from or into osx / os9] - pity it seems to have been taken down! [google still has some of it though].

I too grew up reading Fravia and absolutely loved his tutorials. One nostalgic evening several months ago I went googling for his tutorials and was saddened to see he had passed.

I've been very curious ever since to know what he wrote in his last post, but unfortunately I can't read Italian and the online translation service I've tried seem to fail horribly. Are there any Italian speakers able to translate this for the rest of us?

http://beri.it/2009/08/28/fravia/

rip. His cracking, reversing and searching tutorials are an amazing body of work.

I cannot upvote this enough. Fravia was brilliant, also check out searchlores, where he views the internet as a binary. Beautiful, beautiful work.

Yes please do, and then submit to HN!

I'd like to add an example from the old days: "Ralf Brown's Interrupt List" [link]. It's a list of interrupts used by various software packages with documented weaknesses (typically register range checks). Whenever I'd write an ISR I'd check the list to avoid collisions with other software. Others would use it for writing exploits, the list contains a plethora of attack vectors.

[link] http://www.ctyme.com/rbrown.htm

"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 thought modern OSs make stack memory non-executable, so this attack fail on modern systems.

Right. This is the biggest problem with learning attacks --- the historical attacks no longer work, but they are absolutely essential to

1) get in the mindset of how to find and exploit vulnerabilities, and to learn from the masters. RTM, for example, wrote the first internet worm and one of the attack vectors was a stack smash. Learn from the masters, and how they thought.

2) Since today's systems are built with an understanding of all these exploits, you have to learn these exploits to understand today's systems. So finding an old linux kernel and writing a stack-smasher is one way to experiment.

You don't need an ancient version. For Linux, "echo 0 > /proc/sys/kernel/randomize_va_space" and compile with -fno-stack-protector.

Generally speaking it is much more complicated to exploit these bugs than they used to be, but often attackers find ways such return to libc, return-oriented programming (which ASLR and other technology is designed to combat) or things like heap spraying.

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/

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

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...

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.

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.

Also one thing I forgot. I used to enjoy wargames back in the day.. that is preconfigured buggy blackbox services that you have to exploit in order to progress to the next level. Vortex and PullThePlug used to be some of the really good ones. If someone wants to learn how to exploit software, these games are a really good start.

I was surprised no one else had mentioned wargames. There are several at http://smashthestack.org/ that cover a wide range of exploits (from simple buffer overflows to format string exploits and md5 collisions). My favorite one was to develop two BF (http://en.wikipedia.org/wiki/Brainfuck) scripts that print out different strings, yet have the same md5 hash.

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)

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

On that list, TAOSSA is probably the book you want if you're looking to sell exploits to The Gruhhghhgq.

I see the book is from late 2006. An honest question for better understanding the security research field: how and how come is it still relevant? Things like algorithms (a la TAOCP) I can understand, as if you prove for example a lower bound for a class of algos it will stay like that forever, but in security research I would imagine the people involved protecting themselves from what is now 6 years old bad practices.

Two reasons.

First, because TAOSSA is an extremely good book.

Second, because TAOSSA deals with the fundamentals of vulnerabilities (with an intense focus on memory corruption issues).

The mainstream exploitation of memory corruption has evolved rapidly over the last 5 years or so, but the vulnerabilities themselves haven't changed. Use-after-free- style object lifecycle bugs are as old as Phrack.

That will help you find C bugs in open source software. Won't do a thing to advance your exploit-writing skills though.

I didn't bring up the list, nor did I make that list for exploit developers. Someone else posted the list, and I said that of the books on it, only TAOSSA would be particularly relevant.

It's amusing that you think finding memory corruption bugs (or, "C bugs in open source software") is irrelevant to exploit development, but, O.K.

I just felt that your post could create mismatch of expectations for someone asking specifically about exploit development..

You're twisting my reply a bit though, I didn't say it's irrelevant. It does not cover binary auditing other than a casual mention (which is what I mean by open source) and it does not discuss exploit writing other than a brief intro of the theory behind them.

Chapter 4, Page 167:

"Exploit creation and software auditing are two different-but highly complementary-skill sets. ...The coverage is not intended as a definiteive guide to exploiting memory corruption vulnerabilities, but it does provide the background you need to understand and appreciate many of the vulnerabilities covered throughout this book."

It then goes on to recommend that:

"Readers interested in learning more about exploiting memory corruption vulnerabilities should pick up The Shellcoder's Handbook, or Exploiting Software ...". It also suggests Phrack and Uninformed journals.

I've read Shellcoder's Handbook and recommend it, however, it is out of date now. Despite this, I don't think the value has diminished, as current exploits build on all of the basics discussed there. Another I recommend is Hacking: The Art of Exploitation. I have not read Exploiting Software.

Vivek Ramachandran's Exploit Research Megaprimer[1] is a good video series for the basics. Peter van Eeckhoutte's article series[2] also provide a good hands on for getting started. Vivek's doing a training course at 44Con (disclaimer: I'm one of the organisers) that covers some of this[3] and looks quite promising but if London's a bit of a stretch you should be able to find training courses at conferences closer to home.

The Shellcoder's handbook is a good starting point too but is getting a bit long in the tooth. Attacking the core is a good starter on kernel bug dev. Both should be available on Amazon.

It's also worth pointing out that if you have a local Def Con chapter it's worth going at least once or twice to see whether or not you like it. Same if there's a local BSides event - these are free events, wildly variable in quality but run by the community for the community. There's also other cons like 44Con, Brucon, Cansec, Defcon etc. if you really want to get into it but these can be quite expensive.

I'm not sure where you're based, but if you're in or near London the local Def Con chapter DC4420[4] is on tuesday downstairs at the Phoenix, Cavendish square near Oxford Circus. I'll be there and will be more than happy to have a chat with you and introduce you to people.

[1] - http://www.securitytube.net/groups?operation=view&groupI...

[2] - http://www.corelan.be/index.php/articles/

[3] - http://44con.com/training/vivek-ramachandran-hacking-with-py...

[4] - http://dc4420.org/

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

Google also had a good introduction on web exploits: http://google-gruyere.appspot.com/

It reminded me a lot of Hack this site[1], which is a bit older, but can be helpful

[1] http://www.hackthissite.org/

Ah, finally. I found that site a while ago, didn't bookmark it and couldn't find it again.

Thanks.

Any others that are similar?

If you wan't to learn to develop exploits I would read some of these few sources to get started...

1. The Shellcoder's Handbook 2. Hacking: The Art of Exploitation 3. Gray Hat Hacking 4. w00w00 Exploiting Heaps

Basically memory exploits all boil down to overwriting the EIP with an address that points to some code that does something.

Of course there are all sorts of exploits, some simply send bad data to crash the server as a Proof of concept.. others are more sophisticated, either way if you can program all you need to do is learn a few methods and then writing the exploit shouldn't be so bad..

This question reminds me of when people in my school ask me "where did you learn all this computer stuff?"

You can't make a list of resources that will get you to your goal, you can make one that will give you the foundational knowledge you need to start, but after that you just need to live in the right mindset and start doing it.

I'm not and exploit developer, but I'd imagine that the following would be useful practice:

1) Find a famous exploit, and read about what it accomplished but not how it was done. Then attempt to redo it. When you get stuck, look at what the original exploit did and continue from there. 2) Do the above on a heavily exploited technology, but only read about a few of the exploits. While attempting to exploit in one way, keep your eye out for other holes that you can exploit and develop an exploit that you hadn't even heard of before. It's probably already been done, but you came up with it independently. 3) Now try the same on something less exploited, but still with at least one exploit that you can follow along with. Try to develop a completely original exploit in this way. 4) Now find something unexploited and dig around for an exploit. Now you have enough practice that you should have the ability to identify a potential exploit when confronted with it.

Of course, you should repeat each of the above steps at least a few times before moving on to the next.

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.

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.

Nope, Charlie is definitely not the typical story. Most of these guys don't even have college degrees.

Do you work in the industry? It's changed significantly in the last five or ten years. There are dozens or even hundreds of small shops in the dc area doing this kind of work and self taught no degree folks are a small minority.

Maybe it's the silent majority. After all, most developers aren't the node and nosql pioneers that get all the press, most are working in some office park doing .net and plsql.

I would say the master->apprentice relationship is quite common.

I'm surprised that no one mentioned my class yet, where I have some of the best people in the world talk about exactly how to learn this stuff.

http://pentest.cryptocity.net

http://pentest.cryptocity.net/careers

Get very good with the instruction set. Get very good at gdb. Then learn about memory management and networking protocols. Look up networking libraries in C.

To start, I'd say have a good C manual (K&R), have a good book for computer systems (Computer Systems by Randy Bryant, but there are other good ones) and a good documentation on gdb. gdb is where it begins.

Expert C Programming is a good book to have around because it discuses some of the more esoteric corners of the C standard. These are the places that you'll end up exploring.

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

+1 for this fantastic site ..

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/

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.

I'd agree with most what saurik said. Mindset is one of the most important things about anything. It's always not about WHAT you do, but about HOW you do it. A person who really learns is someone, who views himself while he does something and repeats it later on to discover what he did, how he did it and what else he could've done.

But that's not the reason, why I'm writing here. Since I started to get better at anything I'm doing, I realised that it's always about the little things. If you see someone do one thing that is small, great and everybody loves it, then what actually happened was that this person did millions of small steps that where stupid before. You just didn't see it. Millions, it's not a joke! And of all these things, a lot of them are about just learning boring things. If you want to become a cracker (I'm morally neutral, so I don't really care WHAT you want to become), then you should start out with learning to code and to learn to code quite well. Then you should learn all about how the internet works. That means learning to code more, and then to also learn all about the network protocols and layers and also about how the hardware is wired. Learning all this will automatically show you the limits of what security can achieve (for example you will understand naturally that there can't be a perfect code. Every code must contain the information it tries to hide, some where. So every code will be broken some day.) and also where people did mistakes. And if you have the right mindset you will find ways to hack systems, that actually don't even involve to circumvent security systems.

To make a long story short: You need both, mindest and a lot of knowledge.

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.

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.

Hanging out on boards, IRC, reading hacker publications will get you access to exploits of others. If you want to develop your own zero day exploits you need to become a really really great programmer. Then gain an understanding of the layers that live between the publicly accessible part of an application and the core system you want access to (usually the OS). Learn everything you can about those layers and how the creator has protected the system from unauthenticated users.

Sometimes you're dealing with completely open source apps. These are more secure but the plus side is that you have access to all uncompiled source code.

Sometimes you're dealing with all or part of the stack that is proprietary. These are sometimes less secure but you don't have access to easily readable source code so you need to use special tools to figure out what the creator has done to protect the system.

If you're trying to get into a specific system, intuition often helps you choose where to spend your energy first. You'll have a feel for what code has the least eyeballs on it or the less competent developers writing it, or less frequent updates so you look there first.

FYI there are two kinds of zero day exploits. The first is one you just discovered and no one knows about it. I think of that as true zero day. The second is one that fits the classical definition of the developer having zero dev days to fix it because they haven't been told yet, but many other folks may know about it. Discovering a true zero day security hole is very hard and getting harder because of the bounties being offered now. Often regular zero day holes are discovered by others who got hacked using it and simply back-tracked the hackers steps.

Hope that helps. I'm the developer of Wordfence, a security plugin for WordPress. Also disclosed the timthumb wordpress vulnerability last year and fixed the hole by rewriting timthumb.

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).

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

I'm currently reading it. It gives a rather basic C introduction (I skipped it) but then it goes into explaining how to inject shell codes, using buffer overflows and getting deep into the assembly of programs. It's definitely great for a start.

I'm reading it now, too. There are a lot of examples (it comes with a VM), but the book is still more conceptual than hands-on. The exploit-exercises site posted above looks pretty good.

The second edition is even better. It skips many chapters from the first edition that you don't really need and it goes into more detail in other more important ones to what OP is asking.

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

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.

The easiest way to learn how to exploit is to learn how to prevent exploits in your own code. There are usually lots of tutorials/articles from that point of view. Some easy examples: once you've learned what SQL injection or XSS is and how to prevent it, it becomes easy (almost a habit) to look to see if other apps have done the same.

Learn the oddities and the specifics in the parsing of a language, keep in memory problems with a very easy, and vulnerable solution and keep your eyes peeled. If you're awake, sometimes you think "This looks vulnerable..." and investigate. If you're lucky, something will go wrong in the site and you press on.

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

Better to link directly to the source ( http://phrack.org/issues.html?issue=49&id=14#article ). Phrack Magazine is a great piece of history of the underground. Even today reading some of the articles provides good insight. After all, the essence of the computers architecture has not changed in all these years.

Well exploit development is quite a broad topic - while the answers below provides answers that should pretty much help provide a certain perspective, I sure hope that this helps too.

Lets start off with Web-application security - the most common of attack vectors are detailed as part of OWASP top 10 - you can read more about specific attacks with simple google searches, there are loads of articles that do the same. In order to write exploits you can try the wargames which are present online, or download intentionally vulnerabile operating systems/applications and practice on them(DVL, DVWA etc). The techniques involved in finding these vulnerabilities include fuzzing, vulnerability scanning, source code audit and manual blackbox testing.

Another area of exploitation is that of binaries that run on a particular operating system. Such exploitation usually requires you to find the vulnerability using reverse engineering/source code audit and/or fuzzing. Writing exploits requires you to have at least a good understanding of the stack layout, calling conventions, asm and shellcode. Of course, in this case I am referring to "overflow" vulns and not logical errors.

In order to practice exploitation, you can try out wargames as they are an excellent resource. There are wargames for binary exploitation(smashthestack.org, overthewire.org), webapp hacking(hacking-lab, hackthissite.org, DVWA, and LOADS more) and crypto(overthewire.org and smashthesite.org have crypto wargames), linux admin hacking(hacking-lab has a few every now and then).

Exploit development requires one to have strong fundamentals and understand how exactly stuff works under the hood. There are quite a few books that you might find interesting based one your interests. If you are into webapplication hacking Id suggest "the tangled web" and "the web application hackers handbook". If you are into binary hacking id suggest "the shellcoders handbook"(there are so many more awesome ones but this ones the best to start off with IMO).

Please note that here I have answered the question "How to develop exploits" rather than questions such as "How do i develop the security mindset" and "How do I find security vulnerabilities".

Hope this helps.

[EDIT]

For purposes of learning do NOT use scanners(such a sqlmap), automation frameworks(for eg: msf for generating shellcode). While I think these tools are AWESOME, they should only be used once you have learnt how they work and when you reach a level that you feel you are unnecessarily doing work that could be automated.

The following comment will likely be deemed controversial—but also critical to understanding how the open source community operates with respect to security issues.

Recognise that a lot of hype and circus has built up around around the field of ICT security. Linus made a very public and passionate argument in mid 2008 on the topic. Some sample quotes:

  So I personally consider security bugs to be just "normal bugs". I don't
  cover them up, but I also don't have any reason what-so-ever to think it's
  a good idea to track them and announce them as something special.
  ...
  To me, security is important. But it's no less important than everything 
  *else* that is also important!

―Linus Torvalds[1]

Part of Linus’ argument stems from the bazaar[2] model for developing software. A separate security ecosystem that works in secret and controls the distribution of source code is a throwback to the cathedral[2] model. Linux continues to be a success because it does not use the cathedral model.

Linux development occurs in the open amongst many selfish parties that sit anywhere on the scale between not caring at all about security to being paranoid about security at the exclusion of all other interests. In the middle of this disorder is someone like Linus who is trusted by the community to balance interests. On one side of the debate is PaX/grsecurity (or similar projects) lobbying for more controls and security features in the kernel. This party is generally happier to trade off factors such as performance and ease of kernel maintenance to gain additional security. The other side of the debate may be supercomputing users or embedded platforms who are not willing to trade off performance.

The security hype and circus around security-related bugs can be very dangerous to the ongoing health of open source software projects. I will use the personal example of Mantis Bug Tracker—a project I have contributed to for the past few years. Many of the contributions I have made to the project are security related—XSS, CSRF, access control, cryptography and more[3]. The CSRF protection in particular is a disgrace within Mantis Bug Tracker—for reasons unrelated to security. A few years ago, some forms within MantisBT were protected by CSRF nonces. Obviously this is not a good situation—every form which results in changes to state or data should be protected. I went through every form (grep -PRn "<form") and added nonces. Great! MantisBT was secure. But it was also very much broken. Numerous users started complaining about security error messages informing them of invalid tokens and the the incorrect possibility that they submitted a form twice. The cause? PHP session time-outs were invalidating CSRF nonces and not only prevented users from submitting lengthy bug reports and comments but also led to the loss of that user supplied information. The trade-off between security and usability was (and sadly, still is) broken.

When usability is broken to the detriment of security, the natural and completely understandable user decision may be to disable form CSRF security altogether or switch to another piece of bug tracking software that is less secure—but also more usable. This is a security failure worth being concerned over.

The bazaar model calls for these issues to be thrown out in public on project mailing lists, bug trackers and source code repositories in the hope that a maximum number of eyes will look over the issue and feel a compulsion to assist with patches in the shortest period of time. Hopefully usability issues about any proposed patches are considered as part of this process, preventing the problem I mentioned above with CSRF nonce time-outs. The cathedral model on the other hand prefers to keep these issues secret amongst a select group of self-titled “experts” (core developers or otherwise). The chance of a quick resolution amongst this small group is smaller than if the issue was public with hundreds of eyes looking upon it. There is also a much greater chance that a small highly biased group will fail to correctly consider all the trade-offs.

In summary,

* Recognise that security is a trade-off against other factors and a balance needs to be struck. Bruce Schneier has been repeating this statement for over a decade on his blog. Linus has been proclaiming it on the Kernel mailing list. It is important.

* Know what the bazaar model of software development is, how it works and why the concept of secret walled-garden development communities in a much larger open source project can be considered offensive.

* Software developers have many “most important” problems to deal with at any time and are often volunteering their time. A bad, demanding attitude from a security researcher will not help.

* Security patches do not warrant a Millennium Prize any more-so than a patch to resolve a severe performance regression, data loss bug or major usability issue. Standing on top of a security pedestal in the sky is the antithesis to gaining respect from open source communities.

* Study the work of programmers who are well respected for their knowledge and experience with creating secure software. Some examples are Daniel J. Bernstein (djbdns amongst numerous other projects), Chris Evans (vsftpd), Timo Sirainen (Dovecot), Wietse Venema (Postfix) and Igor Sysoev (Nginx). If you want to make a contribution to ICT security there is no better way of doing it than creating your own secure-by-design software that is relied upon by billions of Internet users each day. The adversarial mindset is important but is not worth much without an ability to practically implement constructive changes.

[1] http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclosur...

[2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...

[3] Refer to oss-security@lists.openwall.com, mantisbt-dev@lists.sourceforge.net, http://www.mantisbt.org/bugs/search.php?project_id=0&cat...

http://nostarch.com/hacking2.htm/

A good book, not hugely in-depth, but enough to bootstrap some learning.

get a random version of wuftpd from the archives. it likely has multiple exploits waiting for you, probably even a remote root

if you need some hints, search "wuftpd remote root" to see the form they often take

check out io.smashthestack.org : awesome wargame with 20+ levels, definitely will give you somewhere to start digging your teeth in.

Reply on news.ycombinator.com