While NoStarch Press gave me an early electronic copy of this book to review before the release date, I have no financial dealings with NoStarch Press or have any other financial ties to this book, it's author or any other entity. While I post reviews to numerous locations (amazon, linkedIn, etc), all reviews will originate on TESTHEAD first unless otherwise designated. Also, while I may abridge reviews for space considerations, I will not post "different" reviews in different sources. If you are curious about the total text for a review, the full review will always be on TESTHEAD.
End Disclaimer.
"A Bug Hunter's Diary" by Tobias Klein is, of course, going to pique the interest of just about any thoughtful tester who sees the title. Bug Hunting is what testers do, after all. Therefore, I feel it important to make a distinction known up front. The sub-title for A Bug Hunter's Diary is "A Guided Tour Through the Wilds of Software Security". Yep, this book is devoted to the "bugs" found related to software security exploits.
This is a fascinating sub-topic of software testing and one that doesn't get a lot of attention. Sure, we hear about the exploits. We hear about the black hat and the white hat hackers that identify them and then help determine how to close the issues (well, some do, there's others that actively "exploit the exploits"). Tobias aims to provide the tester interested in learning about how to test for security exploits; to be a "Bug Hunter" is the books focus and definition. Understanding the approaches used to help ferret out security vulnerabilities, testing the vulnerabilities, and reporting the vulnerabilities to the service provider and vendor, along with case studies for a number of bugs with interesting back stories makes up the bulk of the book.
Lots of people approach bug hunting for many reasons. Some do it for fame, some do it for fun, some do it for altruistic purposes, to help a company make a better product. Some do it for nefarious purposes, to steal information, money and sometimes both. Plain and simple, there's no one reason, but there's a common goal. Software systems are vulnerable. Even the big players with ultra tight security are vulnerable if the right attack is applied. Software testers by avocation are generally interested in this fact, an much can be learned by a tester by focusing on security vulnerabilities. There are two primary ways to find exploits in a system. One is knowing the source code and identifying it through the code paths. The other is the act of actively debugging or fuzzing the software while it runs. Static code approaches can come from reading the source code, if it's available, or through disassembly (which gets covered later in the book). The security vulnerabilities or exploits discussed in this book are mainly tied to memory errors. While there are others like SQL injection an cross server scripting, they are not the focus of this book, and thus are discussed in passing but not in depth.
The book starts out by introducing the reader to the idea of how to look for exploits in software, and that in many ways, gaining access to these exploits can give the user control of the operating system. The book then progresses to seven different case studies, ranging from media file players, system kernels and applications that run on the desktop or in a browser. There's even an iPhone exploit just to show that mobile is just as vulnerable to attacks as anyone else. Many of the methods that are described are definitely technical in nature (well, I should say that they feel technical to me, being that I'm not an active C coder), but even with that, Klein makes the process orderly and fairly easy to follow. You may not get the underlying code, but you understand the thinking process and the sequence of events that he is describing. Even if you are not an active coder or professional software developer, there is much to appreciate here and learn from.
Each chapter is formatted the same way:
The case studies each start with a "Vulnerability Discovery", which goes into the details of how Tobias was able to find the exploit, usually involving debugging code or in some cases reverse engineering objects. In each case, Tobias walks the user through the steps he took to find the issue.
The next section is "Exploitation", which describes how to demonstrate the exploit and show the process to confirm the exploit.
"Vulnerability Remediation" follows, and describes what the company dd to fix the exploit, and some tests to show if the exploit was fixed, or if there were still issues that required additional fixes.
The "Lessons Learned" section shows what software developers would need to consider when it comes to coding to avoid the issue described. It also shows users what they would need to consider when they are using these applications. This little section is a true piece of gold for testers, as it summarizes the areas that are possible issues, as well as avenues as testers we can explore.
The "Addendum" primarily shows how long it took from the discovery of the issue to the ultimate resolution of the exploit. Interestingly, many of the open source exploits were handled very quickly (within days in some examples) whereas larger corporate applications took considerably longer from initial discovery and reporting to when the issue was resolved.
Each chapter also has an extensive "Notes" section to show where to research areas discussed with each case study and URL's to tools used to discover the exploit and demonstrate it.
Appendix A walks the user through a number of different methods, in more depth than in the case studies, as to how to focus on bug hunting in the context of this book. Appendix A includes discussions of Stack Buffer Overflows, NULL Pointer Dereferencing, Type Conversion in C, and Global Offset Table (GOT) Overwrites. Appendix B discusses the various debuggers available to the user on various platforms (Windows, Linux, Mac, etc.). Appendix C discusses Mitigation. You've become more familiar with vulnerability exploits, not here's a chance to get into the various systems and understand what they do to help blunt the ability of exploits to affect your system.
Bottom Line:
A Bug Hunter's Diary is a great and focused glimpse into the world of vulnerability exploitation, and the approaches described will be of interest to a range of individuals. If you are a developer, you will learn a few new tricks as to how to harden your own coding style and applications. If you are someone interested in security, you will see the variety of ways in which software is vulnerable to attack. If you are a tester, you will gain an appreciation for the variety of techniques that can be used to find and exploit vulnerabilities (even if you are not a coder). Regardless of your background, Klein's book has something to offer anyone for whom software security has more than a passing interest.
2 comments:
Interesting concept for a book that it focuses on case studies, sounds like it is worth a read.
Besides for the obvious valuable lessons learned from reading the book, are the case studies written in a engaging way, or are they more on the dull side?
-Simon
Hi Simon.
The examples themselves use a lot of C code and walk through how to use a programmatic method of finding the exploit. IF you are not a coder, a lot of this is going to go over your head (I'll admit much of it did for me), but it's written in a way that, even if you just sort of gloss over the code, the actual exploits and finding them, explaining them and understanding their impact is still accessible to the reader. With that, I found the case studies interesting, even if the minutiae of the code examples I often just scanned rather than read in depth.
Post a Comment