«Ï» çÅñ H@Çk ¥°Ü·
What the hackers do, and how to keep them from doing it

The Making of a Hacker

Picture, if you will, a parasite that calls itself an "immunity tester." Our immunity tester travels from host to host, "testing" to see if it can feed off that particular host. When the feeding is good, our parasite tosses a few chunks of meat in front of the sharks. The feeding frenzy begins.

You'll know the feeding frenzy when it happens. You've been hit by the password traders. Unless you have frenzy protection, your bandwidth use will go through the roof. Someone needs to pay that bandwidth bill - but it won't be the sharks or the parasites.

In spite of the feeding frenzy, our parasite is a responsible parasite. He's careful to not destroy or otherwise damage the host. Sure, he starts the feeding frenzy, but the frenzy itself is not his concern. He'll add one or two passwords to your members area rather than two hundred. Two hundred might get noticed.

If he's cracked hundreds of your passwords, he'll only post a few at a time for the sharks. You'll focus on the few, without realizing that hundreds are known. As our parasite trickles out the "fresh" passes, he remains a hero for continually doing such great work.

Almost every hacker board calls itself the top resource for "security testing." They are "educational" in nature, and not for profit. If you're a webmaster, you can ask the board owner to remove all references to your site from their board - and they will.

Hackers divide their work into two basic categories, cracking and exploiting. Cracking is the process of decrypting passwords so as to gain access to the members area of a paysite. Exploiting is the process of doing stuff you weren't supposed to be able to do, so as to gain a copy of the password file for cracking purposes, or gaining access to other interesting information on the paysite's server.

The sharks, by the way, must move quickly. That's the reason for the feeding frenzy. There are so many sharks looking for fresh passes, that the passes last mere hours or even minutes. Shark traffic hits with a sudden heavy surge.

As a freeloader, how do you get away from the other sharks killing your passes? Your two choices are time, or money. For ten dollars a month, or twenty five, you can become a "special" member with access to longer-lasting passes. Yes, the not-for-profit board owners are selling stolen access to your bandwidth. It's a tough sell, though. The freeloaders are freeloaders.

Your other option is to become a hacker yourself. Create your own passes! You can keep them to yourself, in which case they may last forever, or you can post them. Posting them makes you a valued contributor to that board. Since you're now a valued contributor, you'll also have access to that "special" area. You can now steal porn to your heart's content.

The best part is... it's easy, with no prior experience required. Exploiting requires you to use your brain, but beginning cracking does not. If you're a clueless freeloader who wants to get all that porn for free, cracking is the place to start. Let's begin.

John the Ripper

Step One.
I stopped by the Openwall Project (www.openwall.com), home of Solar Designer's legendary John the Ripper password cracker. I installed it and grabbed a password file (with permission) from one of my customers' paysites. I ran John the Ripper with its default settings like this:

./john passwordfile

How simple is that! I had dozens of passwords cracked within about 20 minutes. I did that my first time. I had no special word list, no specialized "cracking" rules, no benefit of other crackers' experience. I grabbed the rest of this customer's password files, and played with John the Ripper's various "modes" as I read through Solar Designer's help files.

By time I read through the help files and several beginners' tutorials available online, John the Ripper had spewed out several hundred cracked passwords. I knew it was good, but I was quite astounded by how quickly John the Ripper can "kill" that many passwords.

Step Two.
I took those results, and several other lists I had laying around, and added everything to John the Ripper's wordlist. If "apple" is in the wordlist, for example, John the Ripper might try such things as apple, Apple, and apple1 through apple99. By feeding your list of usernames and your list of known passwords into the wordlist, you create a snowball effect. John the Ripper can make more educated guesses based on what's been found already. As you go through cycle after cycle of cracking and feedback, John the Ripper becomes that much more powerful.

I cheated a bit... I seeded the list. I grabbed a bunch of cracked password listings off the hackers' boards. I added each of those usernames and passwords to my wordlist. Since I already had the listings saved on my hard drive, I only needed about ten minutes to add a hundred thousand words to my list. (I then realized I'd inserted a lot of still-encrypted passwords, and took another ten minutes to clean the list.)

Step Three.
I grabbed another password file, without permission. Once you're allowed into the "elite" areas of the hacker boards, you'll find the secret keywords for hundreds, probably thousands, of paysites. Depending on the "exploit" listed, you'll be able to add your own password to the site, harvest the live password file, or even look around the entire server. I pulled the password file.

John the Ripper cracked over a thousand passwords from that file within two hours! My total time spent, counting from when I first visited the Openwall Project to download John the Ripper, was less than four hours.

Imagine, if you will, someone who gets really good at this. John the Ripper can run on anyone's desktop PC 24 hours a day 7 days a week. Just feed it new password files occasionally, and post your results so the freeloaders can have "fresh" passes daily. It's so simple that kids can do it - and I strongly suspect that they do. Since it really is that simple, you can see why the "hacked password" problem is as large as it is.

A Side Note

I personally feel that the current ease of paysite hacking presents a serious legal issue. We are not exercising real diligence in keeping the material inaccessible to minors. Perhaps calling it a legal issue is putting it too strongly - for now. Yet the fact remains that fourteen year olds can crack passwords as easily as eighteen year olds.

Regardless of how they got there, minors can get in all too easily. In my opinion, that is a problem. The problem is easily solved - but we must choose to bother to do so. All we need for a short-term solution is (1) an appropriate password-choosing policy, and (2) properly-written billing scripts. For the moment, that really is all we need. (The better solution is to improve our authentication procedures. Human nature - and the Law of Software Inertia - guarantees that won't happen until we're forced to do so.)

As we continue "the making of a hacker," please bear in mind how easily minors can do this. Remember that legally speaking, it's our obligation to keep them out, rather than to expect minors to refrain from coming in. Remember that we actually can choose to keep them out.

Advanced Cracking

The next step would be to apply your skill and experience to the specific password file at hand. If you know all passwords are eight random digits, for example, you can search accordingly. John the Ripper has its own programming language wherein you can tell it what approaches to take.

Suppose you have managed to crack a few passwords, and discover that when the username is firstname.lastname, the password is first initial followed by last name followed by 1-5 random digits. You can crack the rest of the file almost instantly! Tell John the Ripper to keep the first letter, drop everything up to the dot, drop the dot and keep everything following the dot.

With a bit of experience, you can make this example even simpler. Many paysites use standard unix-type passwords, called DES encryption. Only the first eight characters of the password are encrypted! So, to use the example above, if the person's last name is seven characters or more, you know the password. No guessing is needed.

Do you see why this is so? The password (according to our assumed rules) is first initial followed by last name followed by digits. But... only the first eight characters are used. So, if the name is seven letters or longer, all the leftover characters (including all the digits) are ignored. So far as the paysite is concerned, the password is that person's initial followed by the first seven characters of their last name.

In the same way, if the person's last name is six characters, you need only try adding a single digit. That gives you a mere ten possibilities to try. Even if the last name is a single character, you only have a hundred thousand combinations to try. Since John the Ripper can run millions of trials per second, the worst possible case will still have you seeing dozens of passwords cracked per second.

Given enough examples, a good cracker can figure out the rules. Assigning passwords that are random ten-digit numbers would seem to make them tough to crack - until you remember that only the first eight digits count. Sure, a hundred million trials is a lot. But... it's possible. And... it's easier than it might appear.

Create a list for yourself of, say, one million eight-digit numbers. You now have 1% of all possible combinations. If your list is truly random, and if your list of passwords to crack is also truly random, you should successfully crack about 1% of those passwords. In theory you'll "kill" about one password per minute, which isn't all that bad. If your results do stay around 1%, you're right on track. However, if your results do not generally meet 1% success, you need to change your assumptions. You can perhaps find a better pattern, and crack a much higher percentage!

Generally, however, people get to choose their own passwords. There are no rules. Does this make cracking more difficult? Quite the opposite! People tend to choose passwords that are easy to remember. They also tend to use the same password (or a minor variation thereof) for several different sites.

Once you've gained the experience of cracking thousands or even millions of passwords, you'll have a pretty good idea of how people tend to make their choices. The huge wordlists (sometimes running to several Gig) allow even more passwords to be guessed outright. You can find other passwords by applying various rules.

For example, someone might think "office" is a good easy to remember password. But, to make it tricky, he changes it to "0ff1ce". The password consists of mixed letters and digits, with the digits not adjacent. That sounds good - except that so many people change "o" to the digit zero, "i" to the digit one, "e" to three. John the Ripper can follow the same rules.

Brute Forcing

Brute Force "testing" is basically a sparring match between the hacker's software, and your server's software. You now have a nice pool of username/password combinations, thanks to your John the Ripper adventure. What are the chances of that same username/password working for other sites? The chances are pretty good, it seems! Some silly combinations such as test/test and admin/admin get you into an amazing number of sites.

Brute Forcing, then, is the process of running down your list, trying each one to see if you get into the site. If you check your server logs, you'll probably see hundreds or thousands of failed attempts, often with usernames tried in alphabetic order. If you watch carefully, you may even see some successful attempts!

Brute forcing is so common that there's not much point in trying to block it. Or is there? Let's look at the sparring match more closely, so you can see what I mean. Take the example of a typical member surfing on in to your password protected members area. You're using standard "Basic" .htaccess authentication with DES encrypted passwords. Let's assume your members area is at /members/index.html.

(This example assumes you're running the Apache server software. However, the server and encryption details aren't the important point here. We're focusing on how "Brute Forcing" works. The general idea applies to form-based logins, session cookies, or pretty much anything else.)

When your member goes to the members area, his (or her) browser pops up a little box asking for the username and password. But... what happens under the covers? Your server logs will show you.

When your member first asks for /members/index.html, the server responds with code 401 (Authorization Required). Your member's browser pops the window asking for the login. The browser encrypts the username and password, and then reissues the request for /members/index.html. This time, however, the username and password get passed along as part of the request.

If the username and password are correct... but wait. How do you know if this is the correct username and password? You don't! What I'm getting at is this: Your site's password file might contain a thousand username/password combinations. If you supplied any combination on that list, you get in. If you were assigned username A, but correctly used username B, you get in.

In theory, if you know all of those thousand passwords, you can get in a thousand different ways. The server doesn't care. If you have a valid username/password combination, that's all the proof you need. The server does not care if the password was stolen or cracked. We make no attempt to tie that password to a specific person or specific IP number.

Typical paysite validation is actually pretty weak - and that's what makes brute forcing viable. Poorly-chosen passwords limited to eight characters are gloriously crackable - thus we have a large pool of likely passwords to try. The server doesn't care in the least if you're the rightful owner of that password. If you make a lucky guess, you're in.

Let's suppose you're running off a cable modem, and can try several passwords per second around the clock. That's a quarter million tries per day. With experience, and a good pool, you'll get in.

Or will you. Don't you think somebody will eventually notice? Probably not! Not until something major happens, like the server's error logs filling up a filesystem, or the bandwidth bill suddenly tripling.

Eventually, though, people will notice. If you're running off a cable modem, your static IP number shows in the server logs. The first ten million entries might get missed, but eventually you will get noticed. One change in the server or router configuration, and you're gone. Forever. You'll also receive a nasty note saying your cable modem account has been canceled.

Proxies

Fortunately, the Internet itself comes to your rescue. Rather than losing your cable account for being stupid, you can work through a proxy. Proxies have two main purposes (other than keeping the hackers in business).

The first purpose is in giving you a channel through a firewall. If you're on a secure corporate network, your computer might not have direct access to the rest of the Internet. What's important is the other way around: The rest of the Internet doesn't have access to you. Assuming you need some means of communication with the outside world, you communicate by way of a proxy. Roughly speaking, a proxy is to your browser what an email gateway is to your email client.

The second reason to have a proxy, is as a tremendously huge browser cache. AOL clients, for example, browse the world via the AOL proxies. You may have noticed that when you update a web page, AOL users may still see the older version for a day or more. That's because the page has been cached in the AOL proxy.

Part of a proxy's job is to be invisible. That is, it's designed to do its thing while staying out of the way. A proxy's function is to make requests on your behalf. It feeds things directly to your browser so that you never know the difference.

However, in the hacker world, proxies serve a truly critical function. They cover your tracks! When you surf into a site, that site's server log records your IP number. However, when you surf via a proxy, it's the proxy's IP number that gets logged. You're now much safer from those annoying letters saying your account has been canceled, or that you may face criminal prosecution.

Now you can do a quarter million Brute Force attempts a day without the server knowing who you are. If you're using one proxy, that one proxy can be blocked. So, the Brute Forcing programs allow you to rotate between, say, fifty proxies. You can specify the number of attempts per minute, when to pause for a bit, and so on. With its easy graphical interface, this tool is quite literally child's play. (Well, perhaps not child, but very probably early and mid teen.)

Do you remember I said that Brute Forcing is basically a sparring match? The standard Apache software makes no provision for dealing with Brute Force attacks. However, some sites do. They detect the attack in progress, and block things as best they can.

But... what do you block, when the attack is based on many different IP numbers and many different usernames? Each browser signature is different. As I understand it, servers will block each IP number temporarily. Use enough proxies, with enough time delay before reusing the proxy, and you may continue the attack.

Another thing the server can do, is lie to the attacker. The Brute Force attacker is looking for successful logins. Therefore, to foil the attack, the server can report everything as successful. The attacker, then, has gained no information from the attack.

That's why I call it a sparring match. The Brute Forcer's trying to fine tune the pacing of the attack, and the server's trying to identify what traffic is spurious while still keeping the paysite open to the legitimate members.

Are the best server admins going to tell you, or tell me, how they handle the attacks? Not a chance! Are the best Brute Forcers going to tell you every last trick of their trade? No. The best I can do is assure you that the battle continues, even though I'm not privy to the details.

Exploiting

Exploiting fits into two stages:

* Finding the hole (called scanning for exploits)

* Using the hole (called exploiting)

Scanning is easy. Pick a paysite and run through a list of URLs which might be interesting. You can download your own scanning program for free. You can do the same with other peoples' URL lists. You're supposed to then shorten your list to include only URLs that you personally know how to exploit. If you've noticed a bunch of weird off-the-wall URLs in your server logs from time to time, you've seen people scanning your site for exploits. You can safely ignore the scanning - unless they find something.

What they found, with the information necessary for its use, is called an exploit. Exploiters post lists of working exploits on the hackers' boards, the same as crackers post lists of working passes, as a means of sharing information. At the same time as the sharks are using the passes, the other crackers are adding those passes to their John the Ripper wordlist.

Several billing company scripts require a secret keyword - and nothing else. If you have that keyword, you can add members or display the entire password file. If that script name is "whatever.cgi" (it isn't!), exploiters know to check a paysite for /whatever.cgi, /cgi-bin/whatever.cgi, and so on.

Some exploiters check the join page to see if that billing company is being used or not. Some don't bother, since checking the usual places takes a second or less, whereas actually "eyeballing" the join page takes longer.

Let's suppose you have (1) found that whatever.cgi is there. You then found (2) the secret keyword, and (3) verified that the script is indeed exploitable (i.e., usable for your purposes). You then (4) harvested your own copy of the password file.

What's next? You have several options. (Remember, my purpose here is to explain what hackers do, so you can better understand how to keep them from doing it.) You can:

* Keep the information to yourself. You can crack the password file and post the results for the sharks to enjoy. You may choose to limit your posting to the "special" area. Or, if you have enough cracked, you might split your results between the "special" and regular areas.

* Keep the exploit to yourself, but post the contents of the password file for others to crack and use. You're a hero for having found it, and you're not giving away your secrets by telling how you found it. You can use that trick to find other files on other servers without other exploiters stepping on your toes.

* Post the exploit, not bothering to personally harvest the password file. You're a hero for posting the exploit, and you don't get any heat for getting caught. The other exploiters, in effect, become the sharks.

You might even pop in and enjoy the site. Most exploiters, though, seem to be too busy feeding the sharks.

Spoofs and Back Doors

Many sites use referrer-based validation. You get to visit the protected area if and only if you came from an authorized location. Since you needed a password to get to that authorized location, we assume everything is proper.

The most common referrer-based validation is with AVS sites, and with paysite plug-ins. The surfer enters his password on the AVS's server, and then proceeds from the AVS server to the AVS site's members area. Since we know the surfer came from the AVS server, we know he's authorized.

Third-party paysite plug-ins such as live video feeds often work the same way. So long as the member came from an authorized members area, he's allowed inside the video feed area.

There's an exploitable weakness in this system. We don't actually know where the surfer came from. It's the surfer's own browser which announces the referring URL. The server does not verify that information. All the hacker needs to do is supply the appropriate referring url, and he's in. He's spoofing his credentials.

Some paysites have "hidden" URLs. If you know where it is, you must be authorized! Once the back door is found, it will be posted, and suddenly your site becomes extremely popular. This technique works quite well for AVS sites which don't have referrer-based (.htaccess) protection.

Keeping the Hackers Out

You really have three problems: The sharks, the crackers, and the exploiters.

First, you need to keep the sharks out. Once a live password has been posted for your site, the feeding frenzy kills your server, and you'll be stuck with the bandwidth bill. So, given that your passwords have already been cracked, you must protect yourself from the freeloaders trying to get in. Your financial survival depends on it. (Several companies offer excellent shark-protection services.)

A good password-choosing policy will keep the crackers from feeding the sharks. It's that simple! The master crackers themselves confirm that they depend on people (including billing companies) using poorly-chosen passwords. When the passwords become uncrackable, they must either find another way in, or intercept them as plain text. (We'll discuss a possible password-choosing policy below.)

The exploiters are a very different situation. The exploiters are what we mean by "hackers" in the traditional sense of the word. All software has weaknesses, and those weaknesses can be found.

However, we really only care about paysite hacking. (We'll assume you have a good security-conscious server admin. You'll pay more, and it will be so worth it.) Here's the key: Nearly every exploit posted on the paysite hackers' boards is based on a weakness in a billing company script. Once you get the billing scripts cleaned up, you have quite probably thrown the exploiters off your server!

To be sure, hackers are hackers. They'll find a way back in. The paysite security procedures we use today are simply not adequate. Today's desktop PCs are more powerful than the codebreaking supercomputers of a decade ago. Desperately horny underage freeloaders have plenty of motivation - and time and tools - to find a way in. Still, if passwords become uncrackable, and billing scripts become non-exploitable, we've eliminated nearly every single thing (except spoofs and back doors) posted on the paysite hackers' boards today.

As you clean up your billing scripts, you need to remember that if you're sharing that server with someone else, you need to get the other guy's scripts cleaned up as well. When an exploiter breaks into the server through a billing script, he'll check the entire server for anything else of interest. Think about it: Can you really afford to share a server with someone who doesn't get hurt as badly if you get burned? You might pay more for a dedicated (rather than shared) server, and you'll be glad you did.

Password-Choosing Policy

Choose good passwords, and the crackers will have a rough time of it. What counts as a good password? If it's one that John the Ripper can't crack, it's good enough. If John the Ripper can crack it, it isn't. Fortunately Solar Designer himself (who wrote John the Ripper) tells us how to make sufficiently good choices. On his website http://www.openwall.com/crypt/ he explicitly places this information in the public domain so that you can improve your security.

First, we need the concept of a "character class." The character classes are digits, lower-case letters, upper-case letters, and other characters.

You must also bear in mind the limitations of your current encryption scheme. For example is upper-case considered different from lower-case? For unix DES encryption (standard .htaccess password protection), upper- and lower-case are different, e.g., "Fred" is a different password from "fred". How many characters are encrypted? DES only uses the first 8, so "Bullwinkle", "Bullwink", and "Bullwinkle&Rocky!" are the same password.

Generally speaking, if only the first eight characters of the password count, you need to include characters from all four character classes. A seven-character password must draw from all four character classes; an eight-character password can get by with three character classes. No password containing six or fewer characters is acceptable.

Since the username is in plain text, you need to watch for any portions of the username which are carried into the password, possibly as a reversed string and/or with i changed to 1, o to 0, e to 3.

Exploitable Scripts

I am not going to tell you how to exploit a billing script. Not here in print, anyway! However, you can pretty safely assume that unless you've done something special, your billing script can be exploited.

Generally speaking, paysite-related exploits fall into two categories: inadequate validation of authorization to use; and breaking into the unix shell with unexpected input data. Sometimes files are visible that shouldn't be, simply due to an improper server configuration. Billing companies seem to forget this possibility, and leave plaintext secret keywords laying around in those files.

Inadequate Validation

Sometimes it's trivial: Check /cgi-bin/ for the script, and it's there. Try it without any secret keyword or any other authorization, and it works. You're in! Some servers allow you to read .htaccess, the password file, or even the server log files. Check the usual places, and use what you find.

Sometimes it's a bit better, meaning more difficult for the hacker. You need a secret keyword to use the script. But once you find the keyword, you're in. There is no further validation.

So far as I can tell, many billing scripts were written by people that had no idea that hackers exist. If you hide the script, it must be safe. On the contrary, hackers have their own copies of the billing scripts, and they're able to read the code and recognize the weaknesses.

How can you be sure a billing script is secure? You probably need to take the same approach as the crypto people do. No crypto system is considered secure until it's been made public. Only when the public has examined it and proven unable to break it, is the algorithm deemed to be adequate.

Security based on secrecy is a false security. When you remember that minors can hack porn sites as well as anyone else, I would suggest false security is worse than no security at all. Assuming we actually care about our minors, we can't afford to keep kidding ourselves about paysite security.

Sure, billing scripts are proprietary. Nobody knows what they look like except the billing company, the webmaster, the server admin, the hackers, and google. Until they're made public, they'll probably remain as exploitable as they are today. But they're proprietary, and thus unlikely to become open to public comment.

Meanwhile, you can tighten up the validation, or have a third party do it for you. As I write this, the scripts which require a valid IP number (that is, it must match one from an approval list) are giving the exploiters fits. They haven't yet figured out how to forge an IP number - unless they can find a proxy within the script's allowed IP number range.

Breaking Into the Shell

Every script is different. The "best" scripts for exploiting are the ones that send user-supplied data into a system call without adequate validation. For example, one script expects the username and password as input data. If, instead, you supply a semicolon followed by a string of unix shell commands, you can find everything that server has to offer, including the secret keyword for the other company's billing script.

Just a Thought

The owners of the paysite hackers' boards complain bitterly about site rippers. Too many freeloading sharks are trying to harvest too many "free passes," and the boards are stealing from each other so as to have more passes to offer their own sharks. Thus the hackers' boards themselves would seem to be vulnerable to bandwidth concerns. Remove their paying customer base, or raise their bandwith expense, and they'll have the same financial pressure the rest of us feel thanks to their efforts.

Most sharks don't bother to hide where they came from. Your server logs will tell you where your site's passwords have been posted. While I won't presume to offer legal advice - I'm not qualified - I suspect you can plausibly argue to the board's upstream provider that you have been financially damaged by the information contained on that board. You can perhaps make the same claim with each shark's ISP.

Some of the hackers' boards do appear to be based in the USA. Some boards seem to be sheltered by that server's webspace provider. However, you may be able to find the provider further upstream less willing to condone the illegal hacking activity.

Just a thought.