Slashdot Mirror
Exploiting Software
What kind of secure are you after? There are many published titles on the topic of software security are numerous, but most of them follow certain patterns. Building Secure Software by Viega and McGraw was mainly concerned with proper techniques and general software engineering mindset without going into specifics. Then there was Writing Secure Code , by Howard and LeBlanc, which provided concrete examples and showed the "right way" to do secure coding. I heard the title instantly became a required reading at world's largest software corporation. It's currently in its second edition.
Secure Programming Cookbook for C/C++ by Viega and Messier, was the hands-on title for those developing C/C++ application with security in mind, as the cookbook recipes generally gave examples of good code, with each chapter providing some general background information on the topic discussed (I reviewed it on Slashdot in September last year).
Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.
From the other side With the variety of books on how to write secure software, and what techniques to use to make existing software more secure, there was a niche for a book targeted specifically to those who wanted to break software. Black hat or white hat, the network security experts always had titles like Hacking Exposed to give them an idea of what was available in terms of techniques and methodologies used out there. For software security most of the articles and books generally would tell you something in the terms "do not use strcpy(), as it introduces buffer overruns".
Great, so I won't use strcpy(), did it make my application more secure? Is it more or less hack-proof? What if I am a tester and required to play with this aspect of the application to ensure the application's security before the product ships? Theoretically hanging out at proper IRC rooms and getting lifetime Phrack and 2600 subscriptions should be enough to cover you at the beginning, however, the learning curve here leaves much to be desired, let alone the fact you will probably be kicked out of the IRC rooms for asking n00b questions. Another path would be to take an expensive training course by someone with a name in the industry, but the price tag for those generally leaves out self-learners and those operating on limited budgets, which adds up to about 99% of software engineers and testers out there.
Exploiting Software to the rescue.
Exploiting Software fills the void that existed in this market. Eight chapters take you through the basics and some advanced techniques of attacking software applications with the purpose of executing arbitrary code supplied by an attacker (you).
The book mainly deals with Windows applications for x86 platforms, and some knowledge of C/C++ and Win32 API is required to go through the example applications. To automate some processes and demonstrate possible attacks the authors use Perl, so knowledge of that would help the reader, too. Some chapters, (e.g. the buffer overflow one) show disassembler output, and while you're not expected to read x86 ASM code as if it were English, knowledge of how the registers work and how the subprocedure calls are handled on this Intel architecture are required. After all, if potential attackers know it, you better familiarize yourself with some low-level code, too.
While discussing various possible attacks, the authors post different attack patterns. The patterns themselves usually appear in gray textboxes and talk about the possible exploit in general terms. After that, a series of attack examples follow, with specific descriptions on what can be done, and how. For example, the attack pattern on page 165 is titled "Leverage executable code in non-executable files." The following attack example is "Executable fonts," and it talks how the font files are generally treated by the Windows systems (they are a special form of DLLs). Thus it's possible to embed some executable code into a font library you're creating, for which the authors provide an example in Microsoft Visual Studio.
What's cool is that all the attack patterns are listed in a separate table of contents (alas, not on the Web site table of contents, which just lists the chapters and subchapters), so you can browse to the attack pattern you decide to learn about, read some general info about it and then study specific examples. The examples themselves are not in the table of contents, which I think is a mistake, as it would make searching for possible patterns much easier. After all, how are you supposed to know that "Informix database file system" (p. 189) is under "Relative path traversal" pattern? Well, unless you know specifically that the line http://[Informix database host]/ifx/?LO=../../../etc/ is the one discussed in the example, you would have to either go through the index hoping no omissions were made, or read the chapter in its entirety.
One of the best chapters of the book, Reverse Engineering and Program Understanding, which provides a good introduction into techniques used throughout the book, is available online from Addison Wesley. By having a free chapter you already have 1/8th of the book, but don't think that the low number of chapters makes this 512-page title an introductory book.
Target Audience
Looks like there are two major audiences and reading patterns for this book: those wanting to fix their systems ASAP and thus using Exploiting Software as a reference, and those using it as a text book to learn about security. I've discussed the organization of the book above, and the reference types will probably be more interested in patterns and examples. For a casual reader (although casual readers wouldn't generally pick up a title with C++, Perl, ASM and hex dumps spread around the chapters) this is a book with great educational value, from two authors who have discovered numerous security vulnerabilities themselves.
Exploiting Software is not an easy title to read. Addison-Wesley shipped me the manuscript copy a month before it hit the bookshelves in its final version, and I found myself going through about two pages an hour. The authors bring up sometimes unfamiliar Win32 APIs and occasionally use ready-made tools available on the Web, so generally I found myself visiting MSDN and Google a lot to read through available documentation and download the latest version of the tools used. The book doesn't come with a CD. Some of the stuff, like inserting a malicious BGP packet to exploit a Cisco router (p. 281) is not really testable at home, and I have some reservations about verifying the example with my employer's routers.
The book is probably apt for 2nd or 3rd year computer science students and above. Besides the variety of languages that I mentioned above, you need to be familiar with the basics of Intel architecture, and generally be fluent with terminology like "buffer," "stack," "syscall," "rootkit," etc., as this is not an "Introduction to..." title. From my experience, you probably won't read it from page 1 to page 512 understanding everything perfectly, but for anyone interested in security and those making a career in software development it looks like a bookshelf must-have.
I interviewed Gary McGraw on the current state of software security, the relevance of the topic to the issues beyond C/C++ and improper buffer usage, and future directions in security. Network World magazine also ran an interview with the McGraw in which he talks about the reception of the book at the RSA Conference, whether the economics is right to invest in building secure systems, and whether his book does more harm by providing a compendium of known exploits.
Alex has written numerous reviews of other software and security titles. You can read more of his opinions at his Web site. You can purchase Exploiting Software: How to Break Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Stupidity? Security is easy. Making software stupid-proof is hard.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
-- Douglas Adams
Check out the best P2P sharing website: MEDIACHEST.COM
Someone ought to combine a guide for writing secure code, but with exploit examples that dissect it from both crack and code perspective. (does this book do that, perhaps? Maybe I missed it, but I didn;t see any indication of that in there...)
Quo usque tandem abutere, Nimbus, patientia nostra?
While I've only read the sample chapter given out at the recent RSA conference, I found it to be extrememly interesting. Useful for those looking for ways to secure consulting gigs fixing blatant security flaws in common software (especially web apps)
Why I love Bruce...
;-)]
"We wouldn't have to spend so much time, money and effort on network security if we didn't have such bad software security."
Is to smart as
"We wouldn't have some many crumbling roads if heavy vehicles didn't drive on them"
Is to insightful. I still say the best way to experience Bruce's mind in action is in person. In his books he's trying to pander to the market [of let's face it less than apt people] and in person he's talking with fairly brilliant people [e.g. me
Tom
Someday, I'll have a real sig.
Note: I did not post this anonymously so I MUST NOT be a troll.
I always save my last mod point to mod up a good troll. You people are too serious.
The authors never state that security is not adequately addressed by software engineers but rather there is no lack of mistakes not to be made in designing a product that is inherently insecure.
We need to use more intelligent environments to protect us from ourselves (and other less good proogrammers :-)).
Like the security manager in Java and the security "taint" stuff in Perl.
Kevin
"It's not the cough that carries you off, it's the coffin they carry you off in" O. Nash
I keep reading all these books about how to fix the holes in existing s/w. How to not build systems that are full of holes. It seems we need a decent foundation and its not C. The DoD tried with Ada to design a language that eliminates a lot of the coding mistakes, but it just wasn't embraced. It just seems we are attempting to layer security on top of an inherently insecure software language.
Yeah, we put all the new guys on security.
Everyone writing code should be giving careful consideration to security. In my experience few developers do, but that number is increasing...
I wonder if they talk about security risks regarding social engineering.
Personally, I find that I rarely need to access the thirty-second element of a thirty element array, and I'd die happy if I never have to type for(i=0; i<offbyone; i++){ again.
I used to think that Perl with taint checking enabled was the cat's meow, but I'm now leaning towards Lisp. For the rest of you, is it fair to blame the programmer when his tools (which are supposed to make his life easier) fail him? Use better tools!
Everybody's a libertarian 'till their neighbour's becomes a crack house.
You can write up about security, and tell people to code properly and validate everything but there are always going to be either exceptionally skilled hackers or totally inept users who will be able to do something that you didn't think of, and cause problems.
:P So all in all it's a good thing...
Look at some of the breaches that have been published in the last few years, and then consider if they are the ones they published (usually because they caught the person who hacked them) how many more are unpublished, either because they couldn't catch the attacker, couldn't figure out how the hacker got in in the first place or because said attacker penetrated so deeply they didn't want to be embarresed by it.
But as a good point, it allows people to keep being employed in the network security industry
If at first you DON'T succeed, Skydiving is NOT for YOU!!
I write security software for a living, occasionally. I'm back in it now, after leaving it for a while out of frustration, among other things.
The problem is that even for us security geeks, its nearly impossible to get management to buy into spending the time to make things secure. Nobody would believe the stories I could tell about having security features gutted 'cause marketing decided certificates were too complicated, or 'cause access control systems were too hard to use, so "just put the built in passwords back in", or "*** wants a copy of the private keys", or "*** told me to tell you to check the private keys into version control". Stupid, stupid...
Until companies start caring about making products that are ACTUALLY secure, instead of just hiring security geeks to act as figureheads, then not letting them do their jobs, then system will continue to get hacked.
It sounds like I thought I was getting when I bought Hacking: The Art of Exploitation by Jon Erickson, which is fairly basic and easy to read level, other than some of the writing is not as polished as it could be. It did get through the basic concepts explained in various classic Phrack articles but without the 'leet speak which drives me crazy.
It sounds like this is a more serious and rigious book, and those that were turned off of Jon Erickson's Hacking might prefer it. I think I will take a look at it.
I think new programmers are likely better served reading something like Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World by Michael Howard and David LeBlanc or Building Secure Software by John Viega than get bogged down in details of this book.
There are harsh sentences for computer hacking, and U.S.-style laws are being pushed all over the world, so I don't see why we should focus on making software "secure". Lawmakers made it clear that they want to be in charge of computer security, so let's not worry about it. The idea is that if programmers don't have to worry about security so much, then software development time gets reduced, which helps the economy.
Ugh that's like saying "most office desks aren't secure since their locks are weak and can be drilled easily".
Part of the problem is one of expectations. When people use insecure components and have unreasonable expectations that the'll magically be safe because one piece asked for a password.
There's nothing wrong with components (desk locks or computers) that expect to be kept in benevolent environments.
Next they'll be telling us Wikipedia's not secure because their password-checker is weak.
It is true that writing bulletproof software is TEDIOUS. However, after watching our test staff I have determined that testing it is beyond tedious. It is mind numbing!
The company I work for makes software for wafer fabrication. If the software fails, no one dies but millions of dollars of materials and time can be lost: we spend a lot of time testing and retesting and verifying our tests and going over scenarios to make sure we get it right. Event with all that, over the last couple of years we've logged over 600+ defects of various types. All the way from a misspelled word on an error message to miss-processed data to crashes. Most of those errors are detected in house and the customer doesn't see them: but I would guess we get 4 to 8 defects reported from customers every month with most being minor but a few are so egregiously bad that should have been impossible for that to make it through testing. But even a small error can cost tens of thousands of dollars or more in losses so no bug is a good bug.
Most other places I've worked have testing in name only. The code is compiled and run for a few seconds: some edit boxes are typed into and the mouse is wiggled around and that's it.
If architects make buildings like programmers write code then every woodpecker that comes along destroys civilization.
I ordered this book just when it came out and got it about an week ago. Im still reading it since I try to read it very careful and Im writing on a review of it and several other books with exploit techniques also. I can recommend this book and it was a nice review..
My _guess_, since I haven't actually read the book, is that it discusses common security practises rather than strange bugs in specific software. I also guess that these security issues are already known among evil-doers.
:)
Or, I just failed to get the joke
Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.
It's kind of sad that a statement like this is even necessary. It's an interesting statement regarding what kind of qualifications are often necessary just to get a typical reader to give you credit for not being an idiot.
- Sighuh?
Read Paul Graham's article Beating The Averages.
As a professional in the security business, I'm responsible for handling tens of thousands of financial transactions on a regular basis. My biggest fear regarding security has more to do with the bad habits my clients have than the integrity of the software I use. When it comes to security, having proprietary software can be advantageous in these situations, as there isn't general knowledge of the system's inner workings freely available.
But the biggest security problem was and likely always will be, people who have access to sensitive information that do not act responsibly. Our systems have never been compromised, but once we transmit information to the client, that data becomes a lot less secure, whether it's from a compromised client machine, a rogue employee or a badly-chosen password.
I'm afraid I exited acroread in disgust.
Sure, by using a tool that is 5x slower you can avoid accidents, but that's stupid. If people would simply learn to use the fast tool more carefully, we'd be ok. Being forced to use training wheels to avoid accidents is insulting.
I find Windows of absolutely no technical interest. They took systems designed for isolated desktop systems and put them on the net without thinking about evildoers, as our president would say.
- Bill Joy
Hacking: The Art of Exploitation
It provided these same thoughts on software design, but also delved into more the ASM side of things. The book went on to state that "there is no such thing as secure code." I believe this statement to be true. With the current patch n sniff state of Windows, it is very easy to overflow a buffer to execute code. I have oft heard someone say my pc is unhackable, I run blah firewall, or X N.A.T. the sad fact is they are as easy to compromise as an unsecured network pc is. With the plethora of IE and other browser vulnerabilities out there you don't need to drive a tank through the front door. Seems though Microsoft left a Window open.
I am Bennett Haselton! I am Bennett Haselton!
Some boogers clearly appear in print in a few places in Gary McGraw's older books. Anyone can go to the library and check for themselves.
it's ibm, still after all these years.
As a slightly biased source of information (I work for the publisher, No Starch Press) I would recommend the above-mentioned title for those interested in software exploits. It's a great introduction to fundamental ways to exploit software. It may not have quotes from Schneier, but it's a great book. Check it out here: nostarch.com
Hyperic Community Manager
There's another side to the problem. It's insidious. And while Microsoft is fully embedded in this tar pit of insecurity, Open Source projects are rarely better.
This problem is "feature requests from users." If very few developers understand security well enough to write secure code, think about how much less end users know. Yet it is the end user who pays us. They're our ultimate boss, even on the free-beer Open Source side of things.
At work I've had feature requirements come to me from marketing that would absolutely eviscerate the product's security. I've also seen bug reports elevated to top priority that that would reduce or eliminate product security.
Here are some hypothetical (I hope) examples to show the dangers of this in the Open Source arena. While some of these might have been absurd a few years ago, with today's hyper-concern of usability, it wouldn't surprise me if they actually got implemented.
"It's too much work changing file permissions by hand, so we need a way to automatically execute arbitrary files."
"It's too much work remembering passwords, or remembering the master password for a password manager, so there needs to be a daemon running that will remember for us."
"Messages in XYZ email client should be automatically rendered in HTML/CSS/Javascript."
"The interface is too cluttered! Hide file name extensions!"
Or my all time favorite...
"Linux needs a InstallShield clone!"
Don't blame me, I didn't vote for either of them!
I don't know why this got voted insightful, but you are making a very good point, although involuntarily:
"Security WON'T work until software engineers and programmers get it into their heads that complicated, invasive security procedures don't work if there are any humans around."
If the security procedures are transparent and easy to use from the user standpoint, they will expend and extraordinary amount of ingenuity and cunning to get around them. Usually more than any product designer can spend to develop the product in the first place. This doesn't only aply to software, but to everything else. If you put a different combilation lock on each filing cabinet (very secure), your office workers will tape a list to the bottom of one desk with all the combinations. If you put a different lock on every door, they'll duct tape over the bolts to keep them from engaging.
The same applies to software. Get over it and develop a protocol that doesn't hurt the user and is secure. It's hard, but not impossible.
Despite all the security flaws being found in software and all the fixes coming out constantly, the man in the street has no idea what we are talking about.
A few years ago I was designing a radio network protocol for an electricity distribution client to control their switches. I said that I was going to encrypt the information, they said "Why?" After explaining the problems they simply replied that they had their own cell phone network for the transmissions, no one would break into it and they weren't interested. I still encrypted it though!
Kevin
"It's not the cough that carries you off, it's the coffin they carry you off in" O. Nash
I have an exploit:
/dev/null /dev/null
rm -f
touch
Engineering and the Ultimate
I want support in a high-level language for a construct like:where the language declaritively specifies what it's going to get for input, validates that input, and causes a catchable exception if it doesn't. Input validation isn't hard, but it's really tedious, which is why people don't do it. The language is supposed to take care of easy tedious stuff for you.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
what about static/dynamic analysis techniques/tools?
If you think that's the foundation of Schneier's career you've not looked at his academic publications. He was a seriously high-powered cryptographer and cryptanalyst in his own right long before he got into writing for a popular audience.
And when he does write for a popular audience, he does an invaluable job getting home the ideas that people seem to miss when they're thinking about this stuff. Some of the ideas he promotes are far from truisms, such as for example his campaign to get insurance companies involved the computer security business in the hope that he can change the economics of the situation to favour better security.
Applied Cryptography was the right book at the right time; the most important thing about it was simply the message that this stuff was no longer secret and anyone could read about it. At the time it was written this stuff was not available on the Net; it was compiled from academic papers that weren't generally available for download.
(Disclosure/bona fides: I know him to talk to from crypto conferences and I once broke one of his ciphers (Solitaire))
Xenu loves you!