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.

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?

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

[joe_the_user]

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.

[unconed]

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/

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

[dacilselig]

I would be interested in seeing some of those blogs

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

[toemetoch]

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

[Maven911]

Yes please do, and then submit to HN!

[wasd]

+1

[lyaunzbe]

+1 for the blog posts.

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

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

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

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

[_b8r0]

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/

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

[benkant]

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?

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

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