Earlier this week, we posted this blog item: Ask the VRT a question. We had a few people write in and ask us questions about Snort, Snort rules and the other obvious Snort related questions. Then, we got something interesting...
mish asks "How do I become a Ninja?"
(His question was a little longer than that, and we of course assumed that he meant "Vulnerability Research Ninja")
We threw this around between various VRT people and it apparently hit the hot button on our Senior Director of Vulnerability Research, Matt Watchinski. Here is his manifesto in reply to mish's question:
1. You need to fix your thought process. Most people see computers and programs as tools that have functions that complete the tasks they need accomplished on a day to day basis. If you see everything around you as something that needs to work to do your job then you'll never see it for what it is, something to break and use to your advantage. The best way I've heard this summed up is "Be Evil".
2. Reading books without ever turning that information into practical knowledge is not going to make a ninja. Only experience will make a ninja, sitting in a library never resulted in anything useful.
Once you have the thought process down, technical skills now come into play.
3. The main thing with technical skills is you don't need to be a master of any of them, you need to be a master of recalling where the information you need is located.
4. Get yourself an old ass RedHat box without PAX/AppArmor/etc make sure stack randomization is off, then go download all the ABO's from Gera. Start working on the simple buffer overflow examples. All the answers are on google if you get stuck (but don't cheat, it's not worth it).
5. After that, you now hate GDB. Time to move on to a real debugger. Get yourself a Windows XP box (no service pack), or a Windows 2000 box with any service pack (VMWare is great, just saying). Start working through the AWBO examples that we have on our blog. These will get you all the way up to SEH exploitation on Windows. (shameless plug about our Fundamentals of Exploit Development class should go in here, and here it is Fundamentals of Exploit Development (pdf))
After completing those, you are by no means a master at exploiting things, but all the basics should now be in place. Additionally, you've probably now read every paper on overflows that can be found by google to help you finish all the above examples. You are also now familiar with WinDBG, OllyDBG, or ImmunityDebugger (WinDBG is better), and are unfortunately familiar with GDB, the worst debugger on the planet.
6. Now its time to try some code auditing. The easiest way to do this is with known vulnerabilities. The best example of this type of work is here http://xorl.wordpress.com/. Start doing exactly what this guy is doing. Also its now time to download the C99 standard, and actually read it. Also since it takes a bit to get, order the Intel OPCode manuals, these are free.
After auditing a couple of hundred programs you'll be relatively familiar with patterns in C and other languages which result in coding mistakes that you can now use to your advantage. It's really all about patterns at this stage, since real software packages are huge, being able to quickly find patterns that might be bad is important, as it lets you skip lots of code and only focus on what is interesting.
7. Now it's time to start using and playing with a couple of other tools. Fuzzers, the best place to start in my opinion is with something like FileFuzz from iDefense. Also check out Sully or Peach. Get a bunch of VM's up and running with different programs and let these things in go in the background, while you learn other things. Eventually, you'll hate these tools so much you'll get that idea that you can write a better one, go with that feeling and start writing a simple filefuzzer. Just learn to hate Sully or Peach and be ok with it, as rewriting one of these takes a long time, and you'll forget a bunch of stuff along the way. However, you might come to like python in the process, not sure if thats a good thing or a bad thing.
8. Hopefully at this point, you've got a couple crashes from your fuzzers. This is where being a master of nothing, but recalling information comes in very handy. Time to start reading RFC's, protocol docs, fileformat docs, or whatever is relevant to the crash you have. It is now time to buy IDA Pro. Work on developing a reliable test case for your crash, so you understand exactly what is happening. This is an art, and isn't something that can be reliably taught, as debugging binary only applications requires tons of trial and error for determining if something is exploitable or not in a lot of situations.
At this point you'll be a borderline alcoholic, from banging your head on some problem you just can't figure out and turning to the bottle in an attempt to dull the pain. It's now time to get a support network, not for the alcoholism, but for your other problem. Alcoholism is fine (not really), if you get really good at this you'll need this to get though your day, when you realize that every tool and software app you run contains massive amounts of vulnerabilities that can be used to own your box. Also if you've written a number of tools in the above process you will now find vulnerabilities in them, because most "in training" ninja's are crappy coders. (Sometimes real ninjas are still crappy coders) (Ed note: actually boss, they all are)
9. Once you get your first actual working 0-day, you will now need to invent a root dance. This is important, as it will used in the future when you find more to signify to your friends that you have a new 0-day. Comes in very handy at a Defcon, as long as you're not playing vulnerability poker, as it will tip your hand. While this seems silly, its very important, since you are now an alcoholic, you need to be able to quickly celebrate your accomplishments, without dulling your senses.
10. Now you essentially have a choice. You have a skill that is worth money, you can strike out on your own and start selling your vulnerabilities, or you can now impress some employer with a portfolio of disclosed vulnerabilities. If you're used to a professional services life, then striking out on your own may be the way to go. However, it does have its ups and downs, just like any consulting job. But this isn't a business lesson, its a "how to be a ninja" manifesto.
11. If you go the job route, it's now possible to specialize. This will really open your mind as you will have to invent new tools and techniques if you pick a realm that has little to no public information. Let's take vxWorks applications as an example. Nothing useful about reversing vxWorks exists on the InterTubes. Sorry, Matasano your singular blog post on the subject doesn't count, and mine probably violates something in the DMCA, so I can't post it.
Now that you've read all of the above I'm going to assume something in the back of your mind says "You didn't answer my question, I asked for specific steps, books, and articles to help me out." Well, unfortunately nothing you will read will ever make you what you want to be, its all about cold hard practical experience. You won't see it unless you go do it, as each adventure will open up new paths to information and ideas that didn't seem relevant until you needed them. Finally, you need to love the quest, and it needs to consume you. If walk into a restaurant and see a computer with a menu on it and your first thought isn't to touch all the buttons and see if it breaks, then you don't love the quest.
If you have a question you would like to be answered, feel free to send us an email (research at sourcefire dot com) with the subject line "Ask the VRT" or post a comment on this blog post Ask the VRT a question.