Solutions in this chapter:

Introduction

This book is intended to teach skills that will be useful for breaking into computers. If that statement shocks you, then you probably aren’t familiar with the legitimate reasons for hacking. These reasons can be security testing, consumer advocacy and civil rights, military interests, and “hacktivist” politics; however, in this book, we’re just going to cover the techniques rather than the reasons.

The use of the word “hack” in the title of this book and throughout its pages is deliberate. We’re aware that this word means several different things to different people, so we’ll explain that in this chapter. We’ll also explain how the book is organized and what you might expect for the skill levels necessary to understand the techniques we write about. This chapter will also take a look at what the current climate is in regards to hacking, reverse-engineering, copy protection, and the law. We wouldn’t want to hand you a new toy without telling you about all the trouble you could get yourself into.

What We Mean by “Hack”

When I was a kid, the online world (as far as I knew) consisted of bulletin board systems (BBSs). On many a BBS, there were text files with a variation on the title of “How to Hack.” Nearly all of these files were useless, containing advice like “try these default passwords,” or “press Ctrl-C, and see if it will break out.” Calling this chapter “How to Hack” is my perverse way of paying homage to such text files. They were my inspiration—my inspiration to write a decent set of instructions on how to hack.

So what do we mean by hack? We mean bypassing security measures on computer systems and networks. We also use the word hack as a noun to describe a clever or quick program. The thing is, in real life (in news stories, conversations, mailing lists, and so on) people will use the word hack or hacker without clarifying what they mean by it. You have to be able to tell their perspective from the context or reading between the lines. This book is no different. In addition, the authors sometimes use terms like script kiddie to mean something related to or derived from one of the meanings of hacker. If you don’t like the term that is being used for the activity in question, then the authors of this book would like to cordially invite you to mentally substitute a word you do like, and pretend that we wrote down the one you would have chosen.

If you really want to read a philosophical discussion about the word, then please check out the Syngress Solutions Web site, and download an electronic copy of the book’s first edition. Chapter 1 in that edition is titled “Politics,” and in it, I go on and on about different meanings of the word hacker. In this edition I have spared you the discussion, and if you go out of your way to find the old one, then don’t say I didn’t warn you.

Oh, and we’re hoping to avoid the usage of “hack” that means “bad writer.”

Knowing What To Expect in the Rest of This Book

Now that we’ve put the “how” and “why” to rest, let’s talk about what is in the rest of this book. The beginner, intermediate, and advanced ratings for each chapter refer to how much background you need for a given chapter.

The three chapters of this book that follow this one are intended provide a little theoretical background. Chapter 2 explores our list of laws that govern how security works (or doesn’t). You’ll see how these laws can be applied to hacking techniques throughout the rest of the book. Chapter 3 describes types of attacks and how serious the potential damage is, and provides examples of each type. Chapter 4 describes the various methodologies that someone (such as yourself) might employ to go about discovering security problems. The first four chapters of this book should be suitable for readers of all skill levels. Advanced readers might want to skip these chapters if they’ve already got the theory down, but we ask that you at least skim the text and make sure there isn’t something new to you there. The “Solutions Fast Track” sections are good for this.

We launch into the hacking techniques starting with Chapter 5. Chapter 5 covers the simplest hacking technique there is—diffing—which is simply comparing code before and after some action has taken place. It’s surprisingly useful. This chapter is suitable for beginners.

Chapter 6 is about cryptography and the various means that exist for keeping information hidden or private. It investigates the amateurish cryptography attempts that we see in use in the world almost every day. We teach you how to recognize, and begin to break, very simple cryptographic-like encoding schemes. This chapter is beginner to intermediate (there is some introductory material for readers with little experience in the subject).

Chapter 7 is about security problems caused by programs failing to properly deal with unexpected user input. This covers things like hacking a server through a faulty CGI program, getting SQL access through a Web form, or tricking scripts into giving up a shell. (Technically, buffer overflows and format string holes also fall under the heading of unexpected input, but they get their own chapters.) This chapter is intermediate to advanced, due to discussions of multiple programming languages, and the need to understand shell behavior.

Chapters 8 and 9 teach how to write machine-language exploits to take advantage of buffer overflow and format string holes. These chapters are for advanced readers, but we did our very best to make sure the topics were approachable from the ground up. Some C and assembly knowledge is required.

Chapter 10 describes the monitoring of network communications—sniffing—for hacking purposes. It shows some simple usage, describes from which protocols you can best obtain passwords, and even some basic sniffer programming. This chapter is beginner to intermediate.

Chapter 11 introduces the topic of hijacking connections. Most of the time, this is an extension of sniffing, except now you will be acting as an active participant. The chapter also covers man-in-the-middle attacks. It is an intermediate-level discussion.

Chapter 12 discusses the concept of trust, and how to subvert it by spoofing. This chapter discusses a number of potential attacks, and is intermediate to advanced.

Chapter 13 covers tunneling mechanisms for getting your traffic through unfriendly network environments (securely, to boot). It has heavy coverage of SSH and is intermediate to advanced.

Chapter 14 is about hardware hacking. This is where the bits meet the molecules. This chapter covers the basics of how to hack hardware for the purpose of gaining a security advantage (think ripping secrets out of a secure device the hard way). It’s a beginner chapter, but actually implementing the techniques will be advanced.

Chapter 15 covers viruses, Trojan horses, and worms—not only what they are and how they work, but also what some of the design decisions are, the various techniques they use, and what to expect in the future. This is an intermediate-level chapter.

Chapter 16 explores the way intrusion detection systems can be evaded, or made to miss an attack. It covers tricks that are effective from the network layer through application layers, and includes topics such as fragments, and exploit polymorphism. It’s intermediate to advanced (you will need to know TCP/IP fairly well).

Chapter 17 discusses how to automate some of your tasks with the help of automated security review and attack tools (after we’ve taught you how to do them all manually, of course). It covers commercial and freeware tools. It provides a nice preview of the next generation of tools that will not only determine vulnerability, but will go on to fully break into a system and leverage it as a jumping-off point.

Last, but not least, in Chapter 18 we tell you how to go about reporting your security problem after you find it. Never let it be said that we don’t encourage responsible disclosure.

Understanding the Current Legal Climate

I Am Not A Lawyer (IANAL): This translates roughly to “I can’t really give you any relevant legal advice, and you really shouldn’t take any advice from me. If you do, don’t say I didn’t tell you not to. However, I’m going to force my opinion on you anyway.”

This book will teach you techniques that, if used in the wrong way, will get you in trouble with the law. Me saying this is like a driving instructor saying, “I’m going to teach you how to drive; if you drive badly, you might run someone over.” In both cases, any harm done would be your fault.

I use a very simple rule: “Do I have permission to do this to this machine?” If the answer is no, don’t do it. It’s wrong, and almost certainly illegal. Now, if you want things to be more complicated, there are all kinds of exceptions and so on. For example, in most places (no, not in yours, go ask a lawyer) port scanning is legal. It’s considered fairly intrusive and hostile, but it’s legal—except where it’s not.

The simplest way to be safe used to be to do all your own hacking on your own network (and I mean your network at home, not at your employer’s, because you can get in trouble that way, too). You want to hack something that runs on Sun Sparc hardware? Go buy an old Sparc for $100 on eBay. You want to hack a multi-million dollar mainframe? Well, you’re probably out of luck there, sorry.

One would tend to assume that it would be completely safe to perform hacks on your own equipment. Well, unfortunately, that’s not strictly true, not if you’re attacking someone else’s software. Many people think like I do, which is that if I’ve bought a copy of a program, I’ve got a natural right to do whatever I like with it on my own computer. Intellectual property laws disagree. In the United States, and by treaty in many other countries, it is illegal to circumvent a copy protection mechanism that is intended to protect copyrighted material. This is part of the Digital Millennium Copyright Act (DMCA.) Technically, it’s illegal to even do this in the privacy of your own home, but if you do, and keep it to yourself, it seems unlikely that you’ll have a problem. If you try to tell other people, though, watch out.

As a safety warning, I’d like to share the extreme case of what can happen with these new laws. It involves a Russian software company, ElcomSoft Co. Ltd., that produces software that can do things like crack passwords, remove copy protection, and recover mangled files. Keep in mind that there is no law against reverse engineering in Russia. One of ElcomSoft’s programmers, Dmitry Sklyarov, came to DEF CON 9 in Las Vegas, and gave a presentation on Adobe’s eBook document format. The format contains some laughable security attempts. The next day, Dmitry was arrested on his way home and charged with “distributing a product designed to circumvent copyright protection measures.” This referred to his company’s product, which converted the eBook format into regular Adobe Acrobat .PDF files. Performing such a conversion by a buyer of one of these eBooks for themselves is (or, I guess, used to be) legal: You are (or were) permitted to make backups.

To make a long story short, Dmitry was arrested on July 17, 2001 and was finally able to go home on December 31, 2001. Adobe had dropped their complaint, due to protests outside of their offices, but the U.S. government refused to drop their case. As it stands, Dmitry is still not off the hook entirely.

By all reports, the techniques that he needed to figure out the “security” of the product were relatively simple. We cover decryption techniques of this nature in Chapter 6.

Please be careful with the information you learn here.

Summary

We mean for this book to teach you the dirty details of how to find and exploit security holes, using techniques such as sniffing, session hijacking, spoofing, breaking cryptographic schemes, evading IDSs, and even hardware hacking. This is not a book about security design, policies, architecture, risk management, or planning. If you thought it was, then somehow you got spoofed.

All holes that are discovered should be published. Publicly reporting bugs benefits everyone—including yourself, as it may bestow some recognition.

You should learn to hack because you need to know how to protect your network or that of your employer. You should also learn to hack because it’s fun. If you don’t agree with anything I’ve said in this chapter, or anything we say in this book, then great! The first thing hackers should be able to do is think for themselves. There’s no reason you should believe anything we tell you without investigating it for yourself. If you’d like to correct me, then go to the Solutions Web site for the book (www.syngress.com/solutions), locate my e-mail address, and e-mail me. Perhaps I’ll put your rebuttal up on the site.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.

Q: Should I adopt the title “hacker” for myself?

A: There’s two ways to look at this: One, screw what everyone else thinks, if you want to be a hacker, call yourself a hacker. Two, if you call yourself a hacker, then people are going to have a wide variety of reactions to you, owing to the ambiguity and large number of definitions for the word “hacker.” Some folks will think you just told them you’re a criminal. Some folks who think themselves hackers will insult you if they think you lack a proper skill level. Some won’t know what to think, but will then ask you if you could break into something for them … My advice is to build your skills first, and practice your craft. Ideally, let someone else bestow the title on you.

Q: Is it legal to write viruses, Trojans, or worms?

A: Technically (in most places), yes. For now. That statement deserves some serious qualification. There are a number of virus authors who operate in the open, and share their work. So far, they seem to be unmolested. However, should one of these pieces of code get loose in the wild, and get significant attention from the media, then all bets are off. If you write viruses, be careful not to release them. You may also want to limit how well they spread as well, just as a precaution. At this point, it’s unclear what might happen to you if someone “extends” your work and releases it. Also pay attention to whether posting such material is against the policy of your Internet service provider, especially if you’re a student. It may not be illegal, but could easily get you kicked off your ISP, fired, or expelled.

Q: Is there any problem with hacking systems that you’re responsible for?

A: In general, if you’re authorized, no. Please take note of the if. When in doubt, get an okay in writing from the entity that owns the systems, such as a school or employer. Lots and lots of people who are responsible for the security of their systems hack them regularly. There is the occasional problem though, such as the example you can read at www.lightlink.com/spacenka/fors.