Comment by daeken | Hacker News Reader

Comment by daeken | Hacker News Reader

I have no idea what his list would actually make you, but it wouldn't be anything I'd consider to be approaching "security expert". So, here's my list, So You Want To Break Shit:

- Learn C. Learn it well. That will give you the level of understanding you need of the way the computer works.

- Learn Python or Ruby. If you can automate something, do it. Computers are better than you at repeatable tasks.

- Learn x86 assembly (to start). Write some C code, compile it down to assembly, and read it; understand how the two map to each other. Get your friends to write stuff for you and decompile it back to C, and have them check your work.

- Learn the basics (at least) of web development. Understand how web applications work, understand the constraints it puts in place, understand the interactions between the client and server.

- Internalize the OWASP Top 10. Understand and be able to recognize and mitigate XSS, SQL injection, command injection, arbitrary file reads/writes, etc.

- Grab old versions of open source software and rediscover known vulnerabilities. Grab the latest versions of open source software and discover new ones. Start off looking for simple things, and know it well.

- Reverse-engineer network protocols. Pick a game, write a server emulator for it. This is a great way to use all your skills up to this point. It's also a lot of fun (it's how I cut my teeth).

- Write a debugger. Understand the interaction between hardware, the kernel, and userland.

- Understand, understand, understand. Ask questions. Ask a lot of questions. In my opinion, the key to security is always asking "Why?"

These are in no particular order, and none of these is more important than the other. It also jumps all over the place, perhaps because that's what I do myself; I may be breaking a web app one day and reversing some hardware the next. But these are things I feel are important, and will give you some direction.

If anyone has any questions, wants direction, or anything else, my contact info is in my profile. The world needs more breakers.

I wonder if we should tighten that first recommendation up: learn C before you learn Ruby or Python.

I've had a lot of trouble bringing people into C that have a strong background in (say) Python, but I don't remember C being all that hard for me --- but that might be because I didn't have any other options, besides Borland Turbo C, when I was getting started.

Also: wow do I hate the OWASP Top 10. Can we just rattle off an HN Top 10 right here? It'll be better.

Totally agreed on everything! Let's do the HN Top 10. my suggestions (in no particular order): SQL injection, XSS, CSRF, force browsing, improper authorization, command injection, arbitrary file reads/writes, remote file inclusion. What else?

My list:

1. DOM Corruption / Javascript Injection

2. CSRF / Clickjacking / Reframing

3. SQL / db-metacharacter Injection

4. Authorization/Forced-Browsing

5. Unauthenticated Encryption and Bad Block Cipher Mode Handling

6. Filesystem/Backend Storage Path Sanitization

7. Exposed Admin/Diagnostic Functionality

8. Memory Corruption Vulnerabilities in Native Code Extensions (cext gems, &c)

9. Shell-out Command Injection

10. Insecure Password Hashes

I feel like mass assignment, resource exhaustion, filter return code mistakes, and wildcard routes all belong somewhere, but they feel too Rails-y for a generic list.

I would love at some point to hear your thoughts on CSRF/clickjacking/etc. From a traditional security background, "validate all input" goes a long way towards making a program secure. But web apps have this little thing called the browser actively conspiring against you. All the inputs are valid in a traditional sense.

Imagine if someone said to write a secure program for some computer. But, btw, there's going to be an attacker logged in via VNC at all times you'll need to defend against. I'd just throw up my hands and walk away.

Obviously this is all appsec. It would be interesting to do a consolidated appsec/infrastructure list, with (obviously you need to do all of them, but there are some infrastructure items which cause security and availability issues, and are thus likely to be exposed even before you are attacked).

I think this is a good list on how to get good at learning to jump between layers of abstraction with gusto, but I think ultimately this all needs to be motivated by a desire to actually exploit or reverse engineer something (as your latter bullets point out).

Learning C super well is important, so is assembly, so is other topics but I think fundamentally, step one needs to be: "I have product X. What is it trusting? What is it trying to protect? How do I get around it?" Then, find similar vulnerabilities and continue on stumbling to the ultimate goal.

To me "Pick a game, write a server emulator for it" is an excellent example of "What is it trusting? What is it trying to protect? How do I get around it?".

But on top of being "a great way to use all your skills up to this point" I think it can also be a strong motivation for picking up new ones.

I agree with both daeken and yan. Moving off that, I think a key to "thinking security" is understanding the threat model of a given thing. I believe this is partially what yan was alluding to as well.

Understanding the function, and boundaries, and interactions of a system, application, protocol, device et al and being able to identify who are threat actors, what the assets to protect are, and what the real threats against the entity are will point you at the more valuable things to start. Far, far too many people gloss over threat modeling because they don't equate it with technical work.

Being able to jump between layers of abstraction --- in both directions, so I'd add "learn the browser JS DOM model inside and out --- has to be in the top 5, probably top 3 all time most useful software security survival skills.

What is the standard reference for DOM mastery?

This is a very good starting document: http://code.google.com/p/browsersec/

(Also, anything icamtuf touches is probably going to be good.)

I'd start with _The Tangled Web_ by Zalewski.

Another document worthy of some study is http://lcamtuf.coredump.cx/postxss/

Yes! This is a great paper which made surprisingly little noise given how important it is.

The idea is: stipulate that no attacker can ever inject Javascript into a browser. Assume we solve that problem completely. Now, how secure are DOM-based applications? Turns out: not that much more secure. Lots of very clever examples.

Regarding abstractions, learn how to puncture them.

I think it was Robert Morris (rtm's father) who said when asked how to break security:

1. Look in the manual for statements of the form "Don't do X"

2. Do X

The problem with the term "security expert" is that it is stupidly vague. You describe a security expert as somebody who knows how to break software. I think Bruce would describe a security expert as somebody who knows what to do once the software is broken (or, perhaps, somebody who knows how to plan for the eventuality of broken software).

Regardless, I think Bruce is right about the mindset: if you want to be good at security (no matter where you want to live in the continuum), you have to think differently. That is why most software engineers are good at writing code that can be easily broken. We think in terms of building up, not tearing down.

I also think you are right: once you decide where you want to live on that continuum, you have to understand it inside and out.

Awesome list for self-study! If you work in a sufficiently large organization, or are well-connected enough to sit and chat with the breakers, get them into a room, and drill them about their processes, their information sources, and their mindset.

Beyond the deep, technical knowledge you'll gain following daeken's recipe, there's a whole set of security thought and security models you'll need to learn. It's hard to figure out and differentiate between threats unless you can think like an attacker, then work a system like an attacker does.

-Learn x86 assembly (to start).

Or better yet build a single bus architecture in something like Logisim[1]. It's much easier to learn a simple instruction set architecture down to the logic gates then it is to learn x86 assembly.

http://ozark.hendrix.edu/~burch/logisim/

The point of learning x86 assembly is that many products you may want to analyze or crack are in fact compiled for x86.

Once you know one ISA, you can learn any of the rest "on the job".

Adding to your understand and ask questions point; make lots of mistakes on purpose (or not) and see if the results were what you expected. the why (or why not) might be the vulnerability.

Slightly off-topic, but could anyone give a good modern C reference-book or tutorial? I have read through K&R, but all the modern approaches are of course lacking.

Reply on news.ycombinator.com