The Hacker mind set

Wonder how a hacker thinks? Take a look at a three year old discovering their world and you have a very good idea on how a hacker thinks, no boundaries, no layers, and the whole world is wide open for discovery. While I might be in convention Hades this week, there were a few rough interesting thoughts that came from this if you paid attention and didn’t let the dismal environment wear you down. One of the interesting points (and this was one of those presentations that didn’t last very long due to technical difficulties) was a quick presentation on how hackers think, and why academia is not prepared to deal with that kind of thinking. If you look at the security industry, we tend to specialize, this person is a forensics expert, this person is a secure coding expert, and this person over here is a log file analyst geek god. Hackers suffer no such specialization, while we exist in silos in how we think, and in many cases how we organize our companies into silos, hackers see the entire picture. Not limited by boundaries or layers of the OSI stack, they seek to find out ways of making something do what they want, rather than what the developer intended. If you have ever produced code by deadline, you know exactly what I am talking about here. Business coders sometimes copy whole cloth out of books sample code, and then tweak it to make it do what they wanted it to do. The amusing part is that the hacker is also copying whole cloth that same chunk of sample code, and tweaking it even further to figure out how to make it do amazing things. This is not an issue with open source, and this is not an issue with sample code in books, this is an issue with the approach that two programmers take, with two very different viewpoints on what they want the code to do. Hackers will spend days with the code working out how to tweak it, how it runs, how it works in the system, how it alters system state, the business programmer will be under the gun, on a deadline, and just trying to make something work. Hackers are explorers, they tend to see the total environment, and if they can’t find tools that will show them the system environment they will make their own. Some hackers go beyond this, to work out how to write exploits based on the sample code provided using their own hand crafted tools to work out state, environment, memory, and addressing issues. While many modern compilers try to work out how to randomize code memory addresses, and will dump some program data into non-executable memory stacks, hackers are always going to try to work out ways around the system, and the security measures put in place. Information security people, and their educational models, really need to teach the more creative side of the house. Take any API off programmable web and you will see what I mean. Download any dot net API, run it through FXCop, and try not to laugh out loud when you see the code quality, the calls that are never used, and all the other issues that will come along with the API you downloaded. Odds are likely that the API you downloaded and tested has been downloaded hundreds of times, and suddenly if you are a good hacker, you write the exploit, you test it locally, and if it works, you have access to hundreds if not thousands of computers that are using the same API. We need to teach security engineers to go beyond the check box, yes you have a firewall, SOX will be happy, HIPAA will be happy, but you are using an API that was not security tested, the hacker will be even happier because they see no boundaries. Tags: hacker, culture, thinking, problem solving, fxcop, api, programmable web, sox, hipaa, security engineer, infosec, hack, humor

"Some hackers can emulate hardware in their minds. Look at some code and run it. Jump into the wire, be working inside your computer, while you are using it, and even enter your brain and make it work for them. There is no way to keep them out. Your only hope is to get them on your team before a competitor does. "