5 ms·
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
by daeken 14y ago
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.
- deleted 14y ago[deleted]
- tptacek 14y agoI 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.
- daeken 14y agoTotally 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?
- tptacek 14y agoMy 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.
- tedunangst 14y agoI 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.
- rdl 14y agoObviously 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).
- SoftwareMaven 14y agoThe 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.
- yan 14y agoI 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.
- rockdon 14y agoI 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.
- tptacek 14y agoBeing 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.
- s_baby 14y ago-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/ http://ozark.hendrix.edu/~burch/logisim/
- Shamiq 14y agoAwesome 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.
- frogtown 14y agoAdding 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.
- schme 14y agoSlightly 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.