Sunday, August 07, 2005

Zombie Hacker Survival!

I have just read Jon Erickson's excellent book, Hacking: The Art of Exploitation published by No Starch Press; followed closely by Max Brooks' The Zombie Survival Guide: Complete Protection from the Living Dead published by Three Rivers Press. Coming from someone who hates reading books, these are two select reads. The first was a detailed but introductory technical reference on exploiting programs, attacking the network, and encryption; the second was a humorous but valuable guide to zombies and how to defend against them.

Hacking leads the introductory C programmer straight into the realm of security. If you can code, you'd better buy Hacking (or at Amazon) now. Hacking is an invaluable introduction into why security holes exist, and how to abuse them. To the programmer, it's a quick smack along side the head with a police baton; now that you're fully awake, you can quit screwing up and start writing more secure code. To the aspiring security expert, it's a step straight towards where you want to be; not only does it tell you what kinds of attacks are possible, but it shows you how to discover them and write your own attacks.

More than half of Hacking is dominated by its focus on exploiting ugly program code. Unlike with common titles which lay into overflows with high level explainations and example programs, Hacking takes you to the beginning and drags you on your face to the end. You start with an example program with a visible stack overflow, and an illustration of taking advantage of this. Like any other book on the topic, after a few short pages you've successfully taken root access for some unknown reason.

Before you know it, the author starts dumping output from gdb onto the page and explaining how he's sorting out the layout of the stack, finding addresses in the environment, and defeating security countermeasures by changing the file name of the program to a string of shellcode. By this time you could drop the book in your toilet and find yourself able to actually write the shellcode yourself, using a text editor and nasm. As you continue, you learn about how to hijack functions with changes to the GOT, utilize printf() to take over a program, and damage function pointers to constantly win skeletal gambling games.

Hacking includes two smaller sections. The first explains packet sniffing, spoofing, and hijacking the network for man-in-the-middle attacks with MAC spoofing and ARP cache poisoning; while the second enters into cryptology, password cracking, and breaking WEP using the flaw in the RC4 stream cipher algorithm as described by the FMS attack. In the scope of Hacking, these topics are less interesting; the author clearly covers them as helpful filler, but at a lesser degree of usefulness than the programming section. Still, for what they are, they do supply valuable introductory information for the inexperienced reader.

Hacking falls short of relating to the real world. When talking about buffer overflows for example, it doesn't reference any worms such as Sasser or Blaster, both of which utilize buffer overflows to spread. It doesn't otherwise bring up history lessons of any sort. Hacking is also not a guide to securing your system; it doesn't dive into address space layout randomization or any other systems with only probabilistic if any evadability.

Even without these, however, Hacking: The Art of Exploitation manages to clearly communicate its topic to the reader, and is a great read for anyone with programming experience. Even if you're not going to enter into the field of security, Hacking should be the first on your list as soon as you can manipulate strings and local arrays in C.

If you like Hacking, you'll like The Zombie Survival Guide. Besides giving your brain a break before moving onto Silence on the Wire (or at Amazon), it may lead you to respect good physical security, including self defense, firearms, and physical barriers. The undead may not be here tomorrow, but it doesn't hurt to be ready.

The Zombie Survival Guide is a a humorous piece, but a very deadpan one. It opens up to detail what exactly a zombie is, their characteristics, similarities and differences to the humans they once were, strengths, weaknesses, fabrications, classes of zombie attacks by size, and how to recognize a zombie attack through government and media coverups. From there it goes on to educate the reader on how to run, defend, or attack when faced with zombies. The culmination leads up to the final scenario of a Class 4 outbreak, zombification of the entire civilized world, and how to start fresh and begin taking the planet back.

The Zombie Survival Guide details weapons, defenses, and survival techniques for journies and camping. It baits the user with the most attractive weapons such as explosives and chainsaws and explains why they are poor choices, often due to mobility, fuel, or the unwieldliness for the precision needed to take down a zombie. It also details defenses impassible by zombies, such as high walls (zombies are too stupid to climb).

The Guide gives the reader the most critical information needed both to run from and to run into a zombie outbreak. Not only is long-term travel out of an infected area covered; but the procedures for an offensive sweep of many environments are explained as well. Stealth, or the blatant ignorance and even avoidance thereof, is critical depending on whether you want the undead to come to you or stay away. Vehicles can be either death traps or godsends, and knowing which to chose based on your goals and which to avoid at all costs for preference of walking is no problem for the reader.

Besides valuable military tactics, there is a detailed account of every known zombie outbreak at the end of the book. These can be quite entertaining as a history lesson, although bear in mind they're completely fabricated. Still, the accounts of heroics and tragedy in rapid passing make for an interesting and colorful read.

The Zombie Survival Guide: Complete Protection from the Living Dead is a humorous yet serious guide to protecting your well-being in the event of a small skirmish or an apocolyptic uprising of the undead. If taken with a grain of salt, it may not only amuse the reader, but also provide valuable information when adjusted for the combat considerations of more likely enemies. Remember: an intruder in your home is more likely to be alive than dead; don't count on him to beat on an unlocked door eternally because he can't figure out how to turn a doorknob, but by all means unload a carbine on him at the first sign of hostility.

Phresh Phish

I recently posted a bug on mozdev about TrustBar. TrustBar is an anti-phishing toolbar that tells you when the current loaded https:// page is using a valid certificate; who verified it; and who it was verified as. This means that when you log into something like eBay or ThinkGeek, you're told that you are indeed logging into them.

What TrustBar will not do is check who a regular http:// page belongs to; validate the action target of a form; or look for cross-domain action. Because of this, sites like PayPal, Amazon, Regions Bank, or Bank of America can raise false alarms of Unprotected log-ins in TrustBar, while indeed submitting to a secure https:// CGI action.

The most vigilant users don't need TrustBar for these sites. They can tell they're being owned by simple factors such as deformed URIs that redirect through Google or by Firefox suddenly not filling in their username and password. As for the others, they'll develop a comfort zone with these sites, accepting that they're secure even though TrustBar false-alarms. During a real attack, they will ignore the alarms, as they're normal.

My bug explains this; details a theoretical attack (which has been outdone; the elaborate javascript tricks I used are unnecessary, evidently); and gives several countermeasures that could be easily implemented by TrustBar 1.0. The author has courteously decided to mark this as INVALID, as he decided that this is not a bug.

More pertainently, he failed to understand that my elaborate javascript mess is not necessary to execute a slick attack like this; he has stated that it would be nice to implement the related countermeasure, but that he can't see how to do it. Other more useful countermeasures were completely ignored.

I have re-explained the danger situations, and how to correct for them with appropriate countermeasures. I also reopened the bug as an enhancement. I urge my readers (if I even have any) to actually read the long post top to bottom, and then post commentary urging the author to consider implementing these countermeasures. These phresh phish need to be skinned alive and I believe it can be done.

Thursday, August 04, 2005

I Will Be Out of the Office

I haven't blogged in a long time. I guess I should have caught up with this blog with the recent goings on, specifically the OK to commit that a cleaned-up version of ProPolice, the IBM stack smash protector research project, got from the gcc mailing list.

As of late I've been working and not working (depending on mood) on a paper about designing a secure and user friendly operating system. Between this and Star Ocean, my time is occupied with little news to put up here. I'll probably post a review of a book I read earlier, a nice piece for those interested in learning exactly how security attacks happen.

As for my paper, who knows how long that will take. It revolves around the proven work of the PaX, GrSecurity, ProPolice, and Hardened Gentoo projects, to name a few. From the openning:

"Defining a Secure and Friendly Operating System" is a general reference plan for designing a secure Linux distribution. The concepts in DaSaFOS are not aimed at creating a specialized operating system; but rather at creating a more generalized system which can function as a home user's desktop with high quality security and excellent performance. DaSaFOS brings together existing concepts and projects to describe what can be done today to make a more secure system.

There is much work to do. After finishing and publishing DaSaFOS, I will begin the basic design documentation and begin the search for funding. The pax-future documentation for PaX gives insight into a post-next-generation technology that would be interesting to research into and implement; by no means is current-day technology, even that unimplemented, feature-complete.

One major strategy is to design an online, inline information delivery system to educate the user on-the-fly as to proper security practices. As rediculous as this sounds, OSMOSIS or Online Simple Memoranda Offloading Secure Information Strategy is the name of the subproject I will eventually create to pursue this effort. By feeding the most important information in the simplest form to the user utilizing a non-invasive, non-intrusive, attention-grabbing interface, the last end of security can be held up. Any user can break his own security, and so our final efforts will be to teach them not to.