
Ask HN: How do you learn to develop exploits? - bcattle
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.<p>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.<p>For the record, I'd say a working hands-on knowledge of this should inform the design of any system.<p>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?<p>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?
======
saurik
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.

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

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

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

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

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

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

~~~
jonnyscholes
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].

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

~~~
TwoBit
I thought modern OSs make stack memory non-executable, so this attack fail on
modern systems.

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

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

------
Hrundi
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/>

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

------
rpearl
Try these out:

"keygen" sort of thing (reversing):

writeup:
[https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...](https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f10/www/labs/bomblab-
writeup.pdf), tarball:
[https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...](https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f10/www/labs/bomb.tar)

Exploiting a variety of buffer overflows:

writeup:
[https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...](https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f10/www/labs/buflab-
writeup.pdf), tarball:
[https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f...](https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f10/www/labs/buflab-
quiet-handout.tar)

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

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

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

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

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

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

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

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

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

------
iuguy
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...](http://www.securitytube.net/groups?operation=view&groupId=7)

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

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

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

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

~~~
DanielRibeiro
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/>

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

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

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

~~~
lawnchair_larry
_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.

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

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

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

~~~
adestefan
_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.

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

~~~
soask
+1 for this fantastic site ..

------
makmanalp
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/>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
xtracto
Better to link directly to the source (
[http://phrack.org/issues.html?issue=49&id=14#article](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.

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

------
dhx
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...](http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclosure)

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

[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://www.mantisbt.org/bugs/search.php?project_id=0&category=security&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=-2)

------
fossley
<http://nostarch.com/hacking2.htm/>

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

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

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

