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.

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.

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)

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.

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

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

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

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

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/

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

Do people really need to also write out their support?

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.

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

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

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

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.

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.

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)

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.

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.

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.

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/

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

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

Thanks.

Any others that are similar?

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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!

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

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

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