What I talk about when I talk about Hacking

Most of the security industry (which I find myself an ever-increasing part of these days) seems focused on the end goal of "popping a shell".

I've honestly never cared about this end goal, it is but a single step in the process for me, a sign of being one step closer to the finish line. In and of themselves, shells and exploitation are simply tools for playing a much more interesting game. I want to understand, I want to play, and I want to break things because I think that facilitates learning.

I abuse the Linux kernel because I think it's a fascinating bit of machinery. I want to take it apart and rebuild it just as a student mechanic would a car engine. I want to find logic flaws in things like NAND flash, not to make fun of the engineers, but to understand why it works the way it does, and map all of its limitations.

I would urge others to do the same, to stop sprinting to the supposed finish line and start really learning the platforms you are exploring. We, as a general rule, spend our days pointing out small (but important) problems in highly intricate and beautiful machines. People on the other side of the fence have spent months or years building and designing these platforms only to see us tear down the house of cards with little regard. We tend to be the proverbial bull in the china shop sometimes. 

Once you start exploring the logical and theoretical constructs that all of our machines are based upon, from laptops and smartphones to embedded and SCADA devices, you can move from the world of single-point exploitation to a mindset of questioning real limitations. This will not only grow your intellect, it will inject a deeper context into what we all do and how we do it.  It can move your toils from a quick and dirty PoC into a truly marvelous exploit, one that is both much harder to patch, and much more helpful to those that truly want to make their products more secure.

Personally, I have found that business and manufacturing-based design decisions can lead to some of the most interesting logical conundrums we face as consumers and users of these devices. Scaling issues in particular are an interesting subset often at the root of our problem space. I hope you wouldn't berate or belittle an architect for designing a house whose structural base could not support 100 stories when the initial request was simply to build a single-family home. That requirement wasn't the original goal, it wasn't designed with those stipulations in mind, and thus the foundation simply wasn't engineered to support that scale. 

In software development and engineering, innovation at the edge can quickly burst past the constraints of the original design (this is a huge problem, of a different nature) and things that once worked perfectly become rife with new and unexpected problems. These problems tend to be exploitable with a quick and dirty PoC, sure, but they also tend to be based on a slow and logical progression of some proud engineer's beautiful baby getting bigger and bigger. 

If we can understand a target platform as well as the builder, we can follow that mindset and find the underlying thread that opened the surface for attack. Unlike our quick and dirty PoC, a better exploit coming from a deeper understanding tends to be highly reusable across targets, as it is really an exploit against how developers were trained to think about problems in the first place. It all circles back to unforeseen consequences of very logical decisions. The machine does not change, but the context has shifted immensely when products go to market and attempt scale.

It is also, in my opinion, a worthwhile endeavor to understand the business mindset that drives our targets. Comprehending the driving factors that pushed a platform into your willing hands also lays a blueprint for your path to controlling it. Some companies put more effort into protecting their intellectual property than they do in protecting their users' data, while others do the opposite. Understanding this, as well as other corporate design cultures, will help you craft your plan of attack, be that plan to help the company be more secure or not (depending on what colour of "hat" you "wear" -- yet another rambling topic covered ad nauseam elsewhere). 

I am in no way saying exploitation itself is easy or boring.  It is a highly complex and truly fascinating subset of the process. Anyone who has explored ROP payloads (and stopped long enough to look) knows they are a truly remarkable and beautiful construct mixed with an old school Punk Rock mentality of Xacto knives and duct tape (cut, splice, reuse your environment and build something new and epic). I do enjoy exploitation and find my personal skills adequate to the task. I am simply stating that it is one part, and not the whole, of the activity. Not a goal but simply a stage.  My goals have always been to learn and improve, not to simply script and pop, but I guess that is clear by now.

In closing, please don't always just rush to a shell.  

Slow down, learn and actually enjoy where the path takes you. Getting to a shell is simply getting back to a place of comfort and understanding. It can be a great tool, but it can also be a crutch of stagnation. Instead, take some time and learn the system.

So let's take one more second and define “hacking” in this construct.

Hacking (n): (in our context) "The exploration of the delta between the artificial design boundaries and the hard physical boundaries of a machine, with the intent of harnessing that information for extracurricular computation"

Hacking(n): (in the human context) "The moral obligation to question and test authority and constraints as they relate to complex systems"

Thanks for the read,

m0nk

Thanks to Enrique A. Sanchez Montellano, Valerie Leige, Sergey Bratus and everyone else who helped me craft this diatribe. Next time I blog, I promise it will be about actual intricate machines and not navel gazing the community.

Here's something no one will tell you

Here's something no one will tell you. Unless you have circumstances beyond your control that force you to do so, don't buy a pentest in Q4.

Your sales rep isn't going to warn you about this, because Q4 is historically the most lucrative quarter of the year, typically around 130-150% of other quarters in terms of revenue.

The rumor mill has it that 2013 will have been a lighter year than 2012 for some assessment teams, with belt-tightening for security spending and revenues down. Q4 is when a struggling practice has a last-ditch, make-or-break chance to dig its way out of the hole of the last few quarters. Combine that with overworked InfoSec teams that are still remediating last year's findings and aren't ready for yearly assessments until now, and you've got yourself the perfect storm.

So what does that mean for you as a client? The same thing it means every year.

Pentesters everywhere are double and triple booked, working holidays and weekends, and sales reps and practice managers are banking on nice bonuses in January. Everyone is working toward the goal of a big quarter, doing their best to fatten up before a slow Q1, like bears about to hibernate.

In all the years I worked as a pentester, I don't remember a holiday I wasn't sitting up late, running a pen or writing a deliverable, all the way up to New Year's Eve. In that state of exhaustion and overwork, mistakes are made. Quality goes down. It's simply unavoidable. Junior resources are brought in to run projects, interns are promoted, and everyone scrambles to cope with the workload.

None of this is to say you empirically can't get good work in Q4, but you'll need to ride herd on your testing team to get it, and choose your resources carefully. Quality is going to be the exception, not the rule, for many shops.

On reading the above, let me rephrase my original statement. Go ahead and buy a pentest in Q4, it's a great time to negotiate and everyone is ready to sell work at a good rate. Just book your start date for Q1, if you can.

Or buy one from us, of course. We don't have interns, or junior resources.