I’ve been frustrated for a long time with the ‘teach me to hack’ mentality. Not because I have a problem with beginners (quite the opposite, actually), but because certain people just never get the concept of security testing in the first place.
Yes, “hacking” is a loaded term. I am using it as “being curious and learning about something to the point where you can make it do something other than what it was intended to do…”
Most hear about this skill and rush out to buy all the “hacking” books they can find. How can I hack SQL? How can I hack Linux? How can I hack web applications? There’s a really simple answer. Learn SQL. Learn Linux. Learn to code web applications. What people call “hacking” actually reduces perfectly into two simple things:
- Deep understanding of a technology
- Making it do something it’s not supposed to do
The beauty is that once you combine a deep understanding with a healthy dose of curiosity, all sorts of ways of abusing said system are presented to you.
This requires talent, skill, and practice — don’t misunderstand. And there are many hardcore developers who understand their technology extremely well but couldn’t hack a vegetable cart. Why? Because they lack curiosity and/or the attacker mindset, so they never get to #2.
Developing on, or mastering a technology, is not only the best method to becoming good at security, it’s actually the only method. Anything less is a 0 in a world where 1 is the standard. If you don’t know SQL then you don’t know SQL Injection. If you don’t know Linux then you can’t break Linux. And if you can’t code a web application then you aren’t really doing WebAppSec.
You can use blunt tools to take chunks out of these subjects (tutorials, automated tools, etc.), but to truly be good at breaking something you must know how it works. Anything less is hamfisting.
Don’t be a hamfister.
Miessler is right about it. I remember when I started trying some SQL injection attacks in my penetration tests. I only managed to make them work properly and to get the data I was looking for after I stopped reading the SQL Injection white papers and started reading more about SQL and the RDMSes documentation. That's valid for practically all aspects of black box security testing.