Kevin Finisterre Reveals His Process for Security Research
Kevin Finisterre is a principal of the security consultancy Digitalmunition, he enjoys testing the limits and is constantly dedicated to thinking outside the box. One of his recent accomplishments was landing a spot the 2010 CRN Security Superstars list. Kevin prides himself on being able to confidently state that as a penetration tester he has hacked everything from utilities providers to police cars. Kevin's primary focus has always been on the dissemination of information relating to the identification and exploitation of software vulnerabilities on various hardware and software platforms.
FREE role-guided training plans
FREE role-guided training plans
FREE role-guided training plans
What motivates you to find security vulnerabilities?
As I have gotten older I have realized that there are two factors that drive most of what I do. The first is a desire to teach others and share with them the way my brain works and operates. For whatever reason, people don't always see things in the same light that I do. Some things that seem to be common sense to me are often the same things that others require handholding with before they have a deeper understanding. The other driving factor for me quite simply comes from not liking to be told 'NO' or 'You can't do that'. I always want to know WHY I can't do something and have the answer backed up with supporting evidence. Apart from that aspect I often take pleasure in presenting my own set of conflicting evidence so to speak. If I can do something that you told me I couldn't and then turn around and show you HOW I did it, I am a happy guy.
What are the primary tools you use, and how do you use them?
Ruby became a fetish for me after participating in the Month of Apple Bugs. That particular collaboration initially turned me on to Ruby and now it is really my primary source of tooled help. I find myself very frequently writing small ruby programs to do my bidding or making attempts at porting other peoples work to Ruby. In general, Ruby takes all of the things that previously made Perl my weapon of choice and makes them feel less sloppy to me. My brain thrives off a rapid prototyping sort of workflow and for whatever reason Ruby is easiest the language for me to get that sort of work done.
As a quick example, I was recently working on a project in which I needed to implement a bit of Charlie Miller style 'dumb fuzzing' logic. Since Python isn't my first choice, I wound up reworking Charlie's code into Ruby which ultimately made it more functional for me.
Most of the code I write tends to focus on reproducing a payload or trigger string for an input validation issue of some sort. Using Ruby has been very helpful for generating those malicious strings and massaging existing data into something I can use to exploit vulnerability.
How do you choose your target of investigation? Do you pick your target application and look for bugs, or look for a genre of bug in many different applications?
Sometimes I feel like the bugs just find me. Quite a bit of what I have discovered over the years has been related to software or hardware that I was recently exposed to or in some cases forced to work on. I am a fairly inquisitive person so I like to take apart the things that I use on a day to day basis. Having that particular character flaw makes it common for me to run across things that others have overlooked. As an example, about eight years ago, I worked in a heavily SCO UNIX oriented environment. If you search vulnerability databases you will notice I churned out quite a few SCO vulnerabilities around that time.
As I touched on above, I like to do things people tell me I can't. So that can tend to drive my research targets at times. Some of the SCADA related research I have done in the past was a direct result of someone telling me something along the lines of "You can't just release SCADA exploits." Well, sure I can. Why can't I? Watch me...
How do you handle disclosure? Which vendors have been good to work with and which have not?
In the past, I used to make great efforts to get in contact with vendors. I am more or less over it at this point. Vendors tend to get touchy and defensive when you ask the wrong questions or questions that they feel are encroaching on their intellectual property rights. Paying versus not paying for support is often the fine line for getting help versus not. At this point in my life, I have better things to do then play political games with a vendor. I have started to look at things more or less as a take it or leave it situation. If I choose to make the effort and get in contact with a vendor, I appreciate at the very least some common courtesies such as an email response or a live engineer that can act like he is concerned. Some vendor responses are just laughable, in my lifetime of doing this sort of thing I have been thanked, praised, scolded, threatened with legal action, and accused of not being "responsible" among other things. In the end the two-way interaction with the people I wind up in contact with 100% drives my attitude and motives to "work" with a vendor to get something reported and fixed.
Oddly enough I actually keep a thank you card on my wall from the Apple Product Security team because it reminds me of my warm / fuzzy experiences with them. It reads "Thank you for your tremendous contribution to Mac OS X security" and is signed by three ninjas whose names I will not disclose. At the beginning of our interactions many many years ago things were not at all what I would consider ideal. Without going into too much detail there were several political hurdles that the security team members quite simply had to deal with when interacting with folks like myself. I can think of a few occasions where I would disclose an issue and unfortunately due to company policy they were unable to communicate further with me about it. Things have changed quite a bit since then. Communications today seem more like those you have with an old friend rather than those you would with an arch nemesis. To me two-way interaction goes a long way with regard to making someone like myself feel compelled to share things with a vendor in the future. Now I have multiple methods of communicating information to the company even to the point where staff have reached out to me in their personal time simply to check up on me. It really has been pleasant.
I really didn't plan on calling any particular vendor out, but since you asked I might as well mention my experiences with Microsoft. Simply put I've still got a bad taste in my mouth. However it would be VERY unfair of me to not commend 'stepto' and 'majornelson' for their work at making sure I was a happy guy during my ordeal with Xbox live pretexting. In general however, most of my interactions with the company have been stuffy at best. Maybe I don't approach them correctly or something like that. But the last few times I have attempted to contact them I've been met with the same sort of stuff I got from Apple in the early days. I recently blogged about an issue I found in Windows Phone 7 as an example. My choice to do so now means my name won't be in the advisory IF the issue is determined to be report worthy. I'm currently in the dark about the item. To paraphrase Microsoft's wording, I have disclosed something that was important before their users had a chance to protect themselves... blah blah blah. Now they aren't talking to me about it anymore.
My blog is fairly descriptive about the whole event. But in short, I thought I found an issue while fuzzing image files. I noted that Microsoft had made attempts to limit the end users ability to gather information about crashing programs. I contacted them to see if I could maybe get some more useful data before I attempted to report further. I didn't want to make a stink over every random crash I found if I was not able to debug it on a basic level. Rather than cluing me into the hidden debug features of my phone they told me that I needed some special developer handset and that it was not possible to debug a retail phone at all. I wound up finding a way to get some basic crash dump information sans extra help from them and I chose to blog about it. In the process, they basically begged me to tell them the details of my potential vulnerability or issue. Since there was no real reciprocation on their end I chose to reach out to the public and post screenshots. Because I recorded myself enabling basic crash dumps and showed myself triggering an issue in mshtml.dll Microsoft considers me to be a non "responsible" person.
Can you guess who I am gonna be compelled to report things to in the future?
What are you working on currently?
I've had Zigbee on the brain for a while now and it has ultimately started me down the path of learning more about hardware security.
What have you found to be the biggest differences between hacking hardware and hacking software?
When you mess up with software, things typically don't start smoking or catch fire. In general, there is usually little chance of electrocuting yourself. With hardware, on the other hand, it can get expensive to make mistakes. You can both shock and burn yourself. On top of that, you break it, you buy another one in many cases. Hardware seems to be a bit more brutal. The phrase "blood, sweat and tears" was certainly put in a new light when I first dove in.
Are the lines between the two blurring? Or have they blurred completely?
For some people there clearly is no line, for me personally it is just starting to blur. I've only recently stepped into debugging hardware. The odd thing is that, so far, what I have looked at made me feel like it was 10 years ago in software land versus now in hardware land. Getting my first logic analyzer setup was really an eye opener for me. I honestly had no clue how chips communicated back and forth with each other. It was just like the first time someone showed me 'sniffit.0.1.2.tgz' sometime around 1995.
What do you think is the biggest challenge facing infosec as an industry?
The end users! The human factor is almost always one of the weakest links in the entire infosec equation. We are weak by nature and we do stupid things. Through the social engineering of human subjects, in my mind, you can deliver nearly any payload to any target.
What should you learn next?
What should you learn next?
What should you learn next?
Where do you see the biggest growth in the use of Bluetooth and what are the security risks that growth introduces?
Considering the fact that Intel claimed Bluetooth was dead about six years ago, and the Farpoint Group did the same almost eight years ago, I find it funny that it is still alive and kicking. I honestly haven't dug into Bluetooth in a few years but it was clear that the mobile handset market was almost made for Bluetooth toys like handsets and car kits. On the other hand, exchanging data phone to phone is almost a no brainer in and of itself. Several years ago, from a security standpoint, vendors were doing the end user a disservice by leaving hard coded passwords like 1234 and 0000 laying around, among other things. I can even recall discovering a new class of bug that I called 'bluelining' in which a new line character could be injected into a message and used to spoof the data that popped up on the user interface of the phone. Each phone really provided individual opportunities for developers to do some fairly silly things. Over the years there has been everything from directory transversal issues to buffer overflow issues impacting Bluetooth enabled mobile devices. I do wish Ubertooth was available back then. That I can say for sure!