News Stay informed about the latest enterprise technology news and product updates.

From exposition to exploit: One security book's story

A new manual that discloses vulnerabilities may have had a hand in compromises at supercomputing centers this spring.

Even prior to its release in May, The Shellcoder's Handbook: Discovering and Exploiting Security Holes drew attention...

to the exploitive nature of the narrative. In a series of e-mail exchanges, lead author Jack Koziol explains the motive behind this how-to for hackers and what's happened since it hit bookshelves. Koziol, senior instructor and security program manager at the InfoSec Institute, co-authored the book with David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta and Riley Hassell.

Why write this book? And why now?

While security researchers with good intentions find most of the thousands of vulnerabilities discovered every year, an increasing number of exploitable security holes are found by persons with malicious intentions; as evidenced by the recent Microsoft ntdll.dll and Linux do_brk kernel overflows. The goal of Shellcoder's is to arm software developers and security pros with the same skills that malicious hackers already have, so they can start to identify these lurking security holes to better secure their organizations and customers.

The zero-day exploits, though a minor part of the book, generated most of the advance attention. Was this intentional?

It's really unfortunate that this is the case. The zero-day was incorporated into Shellcoder's to demonstrate that the vulnerability discovery and exploitation techniques in the book can be used to find and exploit holes in real software found in the wild, not just 10-line sample C++ programs. We, as a community, need to learn how to secure HTTP daemons with millions of lines of code, not the same sample program written for the 1996 issue of Phrack.

There's also been a link between your published vulnerabilities and recent network compromises at supercomputing center networks nationwide.

Judging by the report published by Stanford [University], the attackers were able to get a hold of valid usernames and passwords for telnet users -- likely via sniffing, and then escalate privilege using one of the recent Linux kernel overflows or the Solaris kernel overflow first released in Shellcoder's. What is interesting about this, is it shows a somewhat non-traditional attack vector. Today, it seems like most admins only rigorously patch against remotely exploitable vulnerabilities, and less against privilege escalation or "local" vulnerabilities. This bad practice must have something to do with these inane "medium and low risk" severity levels assigned to local vulnerabilities. When the entire TerraGrid gets rooted, these vulns sure seem worthy of a "high" severity to me.

Overall, though, the book's been well received, yes?

I personally feel that the best way to secure a system is to understand the methods the system is attacked in practice, in the real world. It seems that a lot of the responses I've received after writing The Shellcoder's Handbook echo this viewpoint to me, that a majority of security practitioners today agree that we should be proactive and are eager to learn new hacking techniques. It seems that almost everyone today gets real value out of understanding how vulnerabilities are discovered, and also the risk posed when they are exploited.

Five years from now, when everyone's remembering " the good ol' days" (assuming Moore's Law applies to talk as well as technology), how will this book be remembered?

As the first book to accurately describe the vulnerability discovery and exploitation process, for people at many different skill levels, and on a multitude of disparate computing platforms.

Dig Deeper on Risk assessments, metrics and frameworks

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.