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'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.
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.
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.
