Val Smith Reveals His Process for Security Research

In our ongoing series of interviews, this week Val Smith answered a few questions and pulled back the curtain a bit on the methods, tools and motivation for the work he does.

Val Smith is the CEO and owner of Attack Research, LLC. Val has been a frequent speaker at conferences like Blackhat, Defcon and Source on topics such as bypassing malware defenses, post-exploitation, malicious cryptographically signed java applets, ERP vulnerabilities and SCADA. Val spends his time reverse engineering, breaking into computers and coming up with novel ways to steal data and cause physical world effects.

What motivates you to find security vulnerabilities?

For me vulnerabilities are a small component in a larger activity. I generally attack systems, where systems are a collection of software, servers, people, proprietary systems, network trusts, etc. and usually with the goal of either accessing a particular data set, or causing a specific effect. In this kind of activity an exploit or vulnerability may just be one step in achieving the larger goal, or may not be needed at all. Having the capability to access a piece of data or cause something to happen is extremely valuable, and so security vulnerabilities are tools that I use along the way to get there.

What are the primary tools you use, and how do you use them?

Due to the nature of my work, I’m not sure I could say I have a consistent list of primary tools. We can use a wide variety of things from one day to the next including IDA Pro, virtual machines, oscilloscopes, multi-meters, sniffers, debuggers, programming languages (C, ASM, Perl, Ruby, Java, etc), Metasploit. The way we use them depends on the engagement. We might need to write a Metasploit module, record a network protocol, write a packet generator, etc.

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?

Often we are assigned an end goal by our client and so we identify pressure points along the way which could be applications, protocols, hardware, etc. We are not your traditional “pick an application, fuzz it, get a crash, write a POC” shop at all.

How do you handle disclosure? Which vendors have been good to work with and which have not?

We have a 0 disclosure policy. We never disclose unless it is the vendor themselves who have hired us to find something. In that case it’s a much different interaction because essentially we are working with them day to day identifying each step of an issue. We have no experience with typical disclosure policies or politics. Every time a bug is disclosed, a valuable capability is lost, and yet everyone is still vulnerable and frequently compromised. We don’t waste our time trying to change vendor behavior, or providing free QA.

What are you working on currently?

Energy systems and aircraft.

What do you think is the biggest challenge facing infosec as an industry?

The fact that the time to push for security was 10 years (or more) ago and it is too late now. EVERYTHING is compromised. Most major software (including open source) has some form of backdoor. Most (if not all) large and important organizations are at a minimum currently targeted and more likely have already been penetrated for multiple years. This comes from my incident response experience. At this point prevention is out the window, detection has failed and we need to come up with what is possible to do next. In my opinion offense is the only real future left, and it’s a bleak one.

What makes a good penetration test? Should there be standards for a pen test?

I haven’t 100% made up my mind about the need for standards, because the way I go about testing is very non-linear. However I have thrown in with the PTES guys and I think at least attempting to wrap a border around what all should be in a test is a good start and I like what they are doing. As far as what makes a good penetration test, it’s simple, figure out what real attackers do, and do that. Do attackers run nmap, then nessus/nexpose, then core/canvas/metasploit and simply try to root as large a list of boxes as possible? No, pretty much never.

Attackers send a targeted, well-crafted phishing email, beacon out on port 443, encrypt and exfiltrate data. Sometimes they laterally attack and sometimes they go after admin/domain controllers, but not always. Attackers use 0day. This is what pen testers should be doing, and in the course of doing so, working with the client’s security functions each step of the way to tweak firewalls, ids/ips, logging, host defenses, etc. A pen test should be a long term, ongoing, subscription, not a once-a-year two-week engagement with a monolithic report at the end.

What have been the benefits and drawbacks to Metasploit since it was taken over by Rapid7?

Metasploit is fantastic, probably the most important tool out there for the exploit developer and penetration tester. The biggest benefit is that HD and the guys have the time and resources to really develop some awesome capabilities for Metasploit, and polish some of the areas it may have been lacking. The biggest drawback is that it has become so large and has so much code that it’s difficult to understand every aspect of it anymore. But that is not a drawback of being taken over by R7, just a symptom of Metasploit’s great success and growth. I also find myself these days liking to use standalone solutions not tied into a larger framework in many cases.