We've all heard the adage that in order to be effective in defense, you have to think "red:" by thinking like an adversary, you can be a better defender. In cyber defense, by knowing more about how software can be exploited, we can build more secure code to begin with.

Our next interview explores this concept with Corey Kallenberg. Corey developed a 2-day class on exploiting software vulnerabilities. Software often contains subtle flaws that can unwittingly leave us vulnerable to attack. Corey's course describes the process of how these flaws are identified and exploited by attackers.

Editor: We understand, Corey, that in order to learn how to secure code, you're teaching students how to exploit it. How do you package your class for cyber defenders?

Corey Kallenberg: My class, Introduction to Software Exploits, covers the very basics of exploiting memory corruption vulnerabilities. Students start with learning about exploiting vanilla stack corruption vulnerabilities, then build up to learning about how heap allocators work and how overflows on the heap can be exploited. Toward the end of the class I touch on using static source code analysis for finding vulnerabilities and also how to use simple return to libc style payloads to overcome DEP [Data Execution Prevention].

My 3-day intermediate course focuses on finding and exploiting memory corruption bugs in the Windows environment. The course starts off by reintroducing the same concepts that were learned in the introductory course, but from a Windows perspective. This course also places a greater emphasis on bypassing the set of exploit mitigation techniques you are likely to come up against on a modern operating system.

The last portion of the class is dedicated to bug discovery and walks the student through the process of fuzzing, crash analysis, and going from crash to exploit. By the end of the class students are able to fuzz an application for exploitable bugs, then use return-oriented programming and other techniques to exploit those bugs in an environment with DEP and ASLR enabled.

[Ed.]: Could you say a bit more about the process of fuzzing? What's involved?

[CK]: Fuzzing is the process of sending malformed data to an application in an attempt to generate a crash. All of the crashes you discover via this method are indicative of some underlying bug in the application. Some small subset of these bugs will be exploitable, meaning an attacker will be able to leverage them to achieve arbitrary code execution in the context of the vulnerable program.

[Ed.]: Why is it important for cyber defenders to know the information you are teaching?

[CK]: It's important for people who write software to know the process that people who break software use. This gives software engineers a better awareness of vulnerabilities and their implications so that they can write more secure code. I also think it's important for anyone involved in low-level system security to be intimately familiar with this information. If you engage modern exploit mitigations from an attacker perspective, you will have a better understanding of the strengths and weaknesses of those mitigations.

[Ed.]: What are the most popular kinds of software exploits that adversaries are using today?

[CK]: The most popular ones today are web browser exploits (Internet Explorer, Firefox, etc.) and document reader exploits (Adobe Reader, etc.). Both share similar advantages from an attacker perspective. Browsing to a website or opening a business document are common day-to-day operations for most users, so it's relatively easy to trick a vulnerable user into visiting a malicious website or opening a document with a malware payload that will ultimately lead them to being exploited. The other similarity they share is that both classes of applications tend to be large and complex from a programing standpoint. The more code you have, and the more complicated that code is, the more bugs will ultimately end up in the application.

[Ed.]: How are these skills put to use on the job to defend against these types of threats?

[CK]: Anyone who writes code should be aware of the most common scenarios that lead to memory corruption situations that could be used to break their software. Also, anyone involved in reverse engineering payloads (e.g., malicious PDFs) that are used to attack an enterprise would benefit from a greater understanding of how those payloads are constructed to accomplish an attacker's objectives.

[Ed.]: What is one of the more useful applications of this knowledge that you've come across in teaching this to others?

[CK]: I think the most useful and universal skill developed in the course is skillful use of the debugger. I generally think of exploit development and bug hunting as "power debugging." Developing exploits against unusual bugs has taught me to be creative with how a debugger can be used, and I've been able to apply the lessons learned there to improve my performance as a software developer when I am tracking down difficult bugs in my own code. Being good with a debugger is a skill that can be applied to a large number of security scenarios, so I think that students who improve their debugging skills with exploit development will be rewarded with improved performance in other tasks as well.

[Ed.]: What prerequisite knowledge is necessary to get the most out of your course?

[CK]: Proficiency in assembly is an absolute prerequisite to understanding memory corruption vulnerabilities. Xeno Kovah offers a good series of courses on x86 assembly that I recommend all of my students take if they are not already intimately familiar with x86. Other courses that students should consider are Reverse Engineering, Malware Analysis, and Life of Binaries. For more specifics on how these topics relate to each other, see the flow charts on the OST website.

[Ed]: Do you plan on offering any follow-on courses?

[CK]: I plan on offering an "advanced" exploits course sometime in the fall of 2013, but I am still deciding what topics to include in the curriculum. The topics I will include are largely dependent on student interest, so please feel free to contact me if you have recommendations for material you would like covered.

[Ed.]: Sounds like an opportunity to help influence which topics would be covered! I'm sure we'll follow-up with you later this year to see how it will have turned out. Thanks, Corey.