How To Hack a Paysite
What the Good Guys Need to Know

One billing company did come to me and say they had changed their code as a result of reading my article. Another billing company changed their code as well, after rather thoroughly showing their president the mess they were in.

If you're plagued by hackers and password traders, it's probably your own billing company who is letting them in. Is that news to you? It's probably news to your billing company as well!

Your billing company could make hacking and password trading a thing of the past. Right now, though, there's no incentive. If you're plagued by hackers, that's supposedly your problem. You, not the billing company, are paying that bandwidth bill for the site rippers. You are perhaps even paying for third party password protection. As things stand now, you can't live without it!

To understand the problem, I need to teach you how to hack a paysite. You'll understand what your billing companies are up against. And you'll see that with a remarkably small effort you can make your hacking problem a thing of the past.

Getting the Attitude

One particular password traders' board was running a fundraising drive. They were looking for donations from the members to pay for their own bandwidth expense. The board owner explained:

Most of you have been receiving free passes since you joined and we have saved you $1000s of dollars. We dont think that a Donation is too much to ask for what you receive in return.

The "free passes," of course, are the hacked passwords to your paysite. Most responses were whiners saying they were unemployed, but would kick in $5 or $10 when they were able. Yes, these are the people sending your bandwidth bill through the roof with their site rippers and traded passwords.

One response, though, shows precisely what we're dealing with. Please take the time to read it in its entirety:

Well I will just start by saying that I think that the owners should be compensated for the bandwidth. I first donated $25 when it was first asked by cueball, this is before gold passes were around and have continued every month to do so. Why, well, one thing its a great site with many great members, lots of stuff here besides passes. Second is the passes, I mean how many members would see even a fraction of these paysites without this site? The problem with most folks is they dont WANT to pay anything, they want everything FREE. Things just dont work that way. If this was my site I would certainely limit the number of those who arent paying so that I could reduce my bandwidth. Second, I would charge everyone a nominal fee, perhaps $10 a month to help offset the costs. Folks, the owners of this site owe you nothing free, so why don't you pony up. What the hell is $25 bucks a month? You can afford a puter, and ISP, and who knows what else. Time to pay the piper. My thanks to cueball and all the others that keep this site running and being such a wonderful site to be a member of.

That's the attitude you're up against. The typical password trader doesn't even know he's doing anything wrong. The passes are there, so use them. If you can post a few "passes" yourself, you're a hero for being so clever and for sharing. By the way, the board's own USA-based hosting company is collecting the donations!

Basic Paysite Hacking Technique

Fifteen years ago, Robert Morris Jr. took down the Internet. This was pretty clever at the time, since it was the first such incident. The funny thing is, today's paysite hackers continue to use the same three techniques. Many of today's hackers - teenagers and college kids devoid of any sense of ethics - are too young to remember.

Here are the three techniques. Neither you nor the hacker kiddies need to remember the details. The automated tools are waiting for you to use:

•A scanner. You've seen police radio scanners, right? It's a device which checks various frequencies, locking onto anything it finds interesting. Check your server logs, and you'll find lots of people looking for files and scripts you don't even have. They're scanning for "interesting" items, and will take note of whatever's found. (In the Morris Worm's case, the scanner was looking for more computers to infect.)

•A known vulnerability. This is called "an exploit" by the hackers. (Morris knew of vulnerabilities in the unix utilities fingerd and sendmail.) Nearly every exploit posted on the paysite hackers' boards is based on a billing company script.

•A password guesser. The passwords on your server are encrypted. So, they're safe, right? Think again! Morris showed how vulnerable they were fifteen years ago. Most billing companies seem to have forgotten this lesson!

Let's Start Hacking

So you want to hack a paysite. Where do you start? With a password file! If you can't find one on your own, visit one of the hackers' boards and you'll find 'em posted.

Not so long ago - perhaps two years ago - a lot of paysites allowed their security files (.htaccess and .htpasswd) to be visible in a browser. If you knew where to look, there it was! Fortunately most server admins have closed up this hole.

On the other hand... this trend seems to be reversing. More and more people have decided to save some money, and become their own server admins. There are more and more one-man hosting companies with great prices - but no security expertise. There are "web appliances" that will configure your server for you. By all means go the cheap route. The hackers will love you for it!

Meanwhile, though, you have a password file. This is a list of all members of your paysite. The usernames are in plain text (john, jacob, jingle, heimer, and so on.) The passwords are encrypted (/Cphz8p6Emb3A, ooxdAVLkmR6/Y, auWXZ/088ALTQ, etc.). That makes them safe, right? Wrong!

Here's how it works. Suppose you have the username:password listed like this:

john:ooxdAVLkmR6/Y

All we need to do is guess the password and try it. What Morris did fifteen years ago, is take the spellchecking dictionary right from the computer he was cracking, and run through the list of words as a guess. Often as not, he found a match! In the above case, try username john password john, and you're in.

Here's the question. How good is your password policy? Are your users required to choose a password at least 8 characters long, consisting of upper case letters and lower case letters and at least one digit and at least one punctuation character? Better yet, do you assign random passwords such as 8p6Emb3A ?

If you do not enforce a password policy, I can almost guarantee you that the majority of your users indulge in easy to guess passwords. They'll use a name, a birthdate, or the word Password just to be cute. If the hackers can find your password file, chances are they can guess most of your users' passwords! Today's cracking programs are extremely powerful, and wordlists run to 2 gig or more.

A beginning cracker's rule of thumb is to crack 50% of the available passwords. And, generally speaking, they can! How will it affect your site if 50% of your paying members get locked out because of password trading activity? Fortunately, the password traders have "ethics" and "rules." They aren't supposed to post more than ten or twenty passwords to your site at a time. They go on to explain that otherwise the site owner might notice, and close up the hole!

Your basic password problem is due to normal human nature. Most people will choose passwords that they can easily remember. The trouble is that if you can remember it, a cracker can guess it. The only solution is to require an extremely difficult to guess password. It does not matter whether you assign the password, or whether you allow the new member to make one up. What matters is whether a cracker can guess it within the next year or two.

How and when does the password get chosen when your surfer signs up as a member? Normally they go to the secure join page, take care of their billing info, and choose a username and password. Here's where your password policy must be enforced! Who controls the policy at that point? Your secure transaction processor!

I cannot emphasize this enough: If your billing company is allowing members to create easy-to-guess passwords, your billing company is responsible for your hacking problem. It really is that simple!

To be fair, your billing company probably doesn't know this. That's because your billing company is run by nice people who don't know how to hack a paysite. But the technique of guessing a password has been around longer than your billing company has been online, and I assure you it is the primary beginners' technique in use today.

I asked some of the master crackers on the Web, whether well chosen passwords are effectively uncrackable. Here are six typical answers. Read carefully, and you'll see the crackers themselves are telling us how to put them out of business:

Hacker One. Nothing is uncrackable. It should take more time and you will need a little bit of luck, but if you use a good wordlist it could be done fast. But in most cases they choose not so clever passes. Also, extra characters like "=+*#$_" are really hard to crack.

Hacker Two. 95% of people use very dumb and obvious passes! Also in 99% of the cases there is a logical sequence in them which is not that hard to figure out. I've written a little tutorial for... and it will almost kill everything if done right!

If you do it my way you'll get everything up to 8 in length. There is another more difficult trick to go beyond that, but there is not much use for it. Usually usernames are longer but passes are in 99% of the cases shorter. This is to make for a quick entry (I guess...).

Hacker Three. I agree with Hacker One. Nothing is uncrackable, but it may well be non brute-forcable, in that the only way to get access would be to view the passfile in plain text, because the passwords are so non-standard that no wordlist would be effective.

The best example of this is a well known AVS. For example,

user: ab98323432 pass: J54a7v6Q526eZ

This password is clearly not guessable, or decryptable, nor brute-forcable by use of a wordlist, so the only way is to be able to view the password in its original plain text.

Hacker Four. It seems to me that no one has pointed out the obvious fact that almost all adult/porn sites don't allow their customers to choose special characters in their usernames and passwords.

There are some sites that let the members choose their own username, and then randomly generate a pass for them using uppercase, lowercase and digits in a wonderful hard undecryptable way (good example here is cdgirls and avs like AB and deluxepass).

There are also sites that use 6-8 digits for both usernames and passes, but all-digit passes are reasonably easy to decrypt compared to a mix of uppercase, lowercase and digits. So the only way to get a chance of decrypting these kind of passes within a reasonable amount of time is to try and get clear text passes if these sites use MySQL or ORacle databases and gain access to these somehow.

Hacker Five. The main reason people pick simple passwords (eg. apple1) is so that they can remember them.

As Hacker Three mentioned there are a heap of sites (like AB) that generate their own passwords and send them to the user.

This creates its own problems though. Let's say the guy whose normal pass is apple1 is named Dim Witt. Dim decides to join AB. He signs up and gets issued with DimWitt@hotmail.com:Aj4pIhDS4sMb

What's the first thing he does? Write down the password because there is no way that he will remember it. He probably also keeps a couple of copies electronically. Now it may be harder for remote users to brute-force his password but not hard for anyone with direct access to his desk and or computer.

One of the other problems with issuing Dim with a password is that he'll lose his scrap of paper and get kicked out of the site. This causes reverse workflows for the webmaster but they obviously think it's better than someone else using the pass.

Hacker Six. The stuff that's being discussed here only counts when trying to guess a pass. If you have access to a server, it doesn't matter how "uncrackable" a pass is, because you can just see & save it. I've seen some servers that put their passfiles in directories like

\web\pass\UG3264--_##UIvc-H87y3shghGkuGFGKS-\.htpasswd

This is in no way to be found by brute force. But when you are there, what difference does it make?

Someone else said it before here, but I totally agree... With new protections finding their way onto the web, bruteforcing as we know it will become a thing of the past. So Sploiting is the way to go...

"Hacker Two" will crack passwords for you while you wait. Send him the password file and he'll have dozens or hundreds (depending on the size of the file) of "kills" for you in mere minutes. Modern cracking tools are that powerful, and the crackers' body of knowledge is that large.

The Buck Stops Nowhere

Let's step back a moment, and consider the situation. Your billing company should take responsibility for protecting your customers' billing information, and your server admin should take responsibility for protecting your paysite. After all, the billing info is on the billing company's server, and the paysite is on the admin's server.

After carefully analyzing the situation, I strongly disagree. Your customers' credit card data is (usually) secure. Why is this so? Because that's what your billing company does. They have firewalls, authentication codes, secure logins, and surely keep a careful watch on outside probing. If they're being hacked, they know it.

But who's keeping that close an eye on your members area? If someone got a copy of your password file, would you know it? If someone quietly added a couple of passwords, would you know that either? Nobody's watching! Your billing company doesn't consider it their responsibility. But if not, whose is it? Think about it: What are you paying them for?

Exploiting the Billing Companies

The basic problem is this: The billing companies are up against some serious technical difficulties when it comes to protecting your paysite. First, the server itself is outside their control. The server itself is your problem, and your server admin's problem. Second, there's a basic security flaw in how servers work.

The first consideration is trivial: Go with a hosting company that knows what they're doing. You'll pay more, and it will be so worth it.

The second consideration is how servers work. Your billing company has their own secure servers. When the transaction is complete, they need some means of updating your members area so that your new customer may surf on in.

How do billing companies do this? By installing a set of CGI scripts on your server. When you first opened your paysite, the billing company probably came in, did their thing, did a test signup, and pronounced you ready for business. So far, so good. Let's call that CGI script the billing script.

What does your billing script do? It updates your members area password file. This is how your billing company adds a new user, deletes an old user, changes a user password, and so on.

Here's the problem. Generally speaking, your server makes no distinction between one CGI script and another. If the billing script has permission to update your password file, any other CGI script on your server can do so as well! Since your billing script is obviously able to read your password file, that means any other CGI script could also read your password file - if it were successfully asked to do so.

If a hacker were to manage to get a CGI script installed on your server, obviously you're screwed. Your password file is wide open. And, as I explained above, your password file is gloriously crackable. Fortunately, getting a script inserted on someone else's server is rare, but it does happen. (Would your admin know it if it happened to you?)

However, it is not hard to find an exploitable script on your server. An expoitable script is one that a hacker can use to get a peek at your password file. Remember, if one CGI script can read the password file, every CGI script can read that password file. That's the basic flaw in how unix/linux servers work.

When it comes to exploiting CGI scripts, reputation doesn't mean anything. Matthew Wright's formmail.pl is one of the most notoriously exploitable - yet I have a $49.95 book on the shelf next to me, CGI/Perl Cookbook by Patchett and Wright. Matt's Script Archive is well known with high traffic.

A lot of people out there use the formmail.pl feedback form. Somebody sticks in their email address, and the form data gets sent to the site owner. Let one user install such a script anywhere on the server, and every paysite on that server is now wide open. That's the kind of problem your billing company is up against! (I believe Matt has a more secure version of formmail.pl available these days, but that doesn't affect the existing installations.)

Everything is readable

So you want to hack a paysite. Do you remember where to start? With a copy of the password file. With a copy of that file - even though the passwords are encrypted - you can literally get cracking. But... how do you get a copy of that file? Isn't it protected from casual view?

The basic rule of thumb is this: On a unix/linux server, you have to assume ANY file is readable. It probably can't be edited, but it can be read. That's how unix works.

The unix folks learned years ago - Morris did the teaching - that the master password file is vulnerable. Since it was readable by anyone on the server, that was a problem. Unix itself changed over to a shadow password file, which was not so easily read. It's now quite rare to hear about a unix password file being found and cracked.

Unfortunately, the billing companies don't have the luxury of hiding your password file. It must remain readable. What's really unfortunate, though, is that the billing companies - several of them, at least - failed to learn the Morris lesson. They completely forgot that any file on a server is readable! Where there's a will, there's a way... and that's an expensive lesson to forget.

Can you imagine leaving a password laying around in a readable file, in plain text? If you can read the file, you have the password. Several billing companies code their master password right into the script, in plain text. Yes, really! If you can read the file, you have the password. If you have the password, you own the paysite. You can add, change, delete members at will.

Did you catch that? Your members area passwords are encrypted. Most of them are crackable, but they are encrypted. However, several billing companies leave the billing script password on your server in plain text. The billing script encrypts the members passwords, but keeps its own password as plain text!

As you can well imagine, these billing scripts are very popular with the hackers. When someone manages to find a copy of that plaintext password, they'll post it on the hackers' board so that everyone can use the script.

Billing Exploits

Is somebody exploiting your billing script? How would you know? Many billing scripts have no tracing, no audit trail, no other validation or protection. If you have the keyword, you're in. Your financial data is safe, but your paysite is wide open.

Other scripts do a bit better with authentication, and do leave an audit trail of sorts. The irony is, that very audit trail is highly prized hacker food! The audit trail shows the passwords, and all too often they're crackable.

If you visit the "elite" areas of the paysite hackers' boards, you'll see that the billing scripts are the most commonly published method of breaking into a server. If you're having a hacker problem, it's very likely that a billing company is your problem. The problem could be your billing company; or the problem could be someone else's billing script on the same server. (This is why you are far more vulnerable on a shared server. You have to worry about your own scripts and the other customers' scripts.)

Have you noticed that I left out a step? To crack the passwords, you need to display a copy of the password file. You can trick a billing script into thinking you're the billing company, and add your own password. If you can do that, you don't need to crack someone else's password! But that doesn't get us a copy of the entire password file.

The other thing you can do with a billing script, is break into the server itself. You can use the billing script to display files that you shouldn't be able to see. You can also display folder contents that you shouldn't see. That's how you find the things which are hidden, and how you find the secrets of other paysites on the same server.

How, then, do you get a copy of the password file, so you can crack it? You use a billing script, somewhere on the server, to display the file. Some billing scripts come with online instructions for the hackers. It tells you how to display the password file, how to add your own username and password, and even how to delete all paysite members.

Online help for hackers - remember that this is helping the hacker to hack your paysite - is nice, but far from the worst. Other billing scripts allow your hackers to run any unix command anywhere on the server. They can install their own stuff on your server, or scan your private areas for hidden webmasters' notes. It doesn't get much better than that!

Exploitable Leftovers

You as a paysite owner grow and change. You might change billing companies; you might move to a different server or ISP. You might open another paysite, and another, and another.

As you grow, it's remarkably easy to copy unneeded scripts forward, and to leave unused scripts still laying around. You might not be using them, but the hackers still can! Those scripts are just as live, and as vulnerable, as they ever were - and chances are you'll never notice if they get used. Nor will those scripts ever receive security patches or updates.

Solving Your Hacker Problem

I've left out certain critical steps to successful paysite hacking. I've also failed to tell you exactly how to exploit the various CGI scripts. If you need proof, I can provide plenty. But the surest proof is your own server logs.

Talk to your billing company. They're your friend - or should be. They have a stake in your success, and vice versa. You have two key issues to discuss.

•Members Area Password Policy

•Billing Script Security

The difficulty, of course, is that these two areas are extremely sensitive. If your customers discover their password has been lifted, they'll also assume their credit card information is unsafe. This is quite untrue - but your customers don't know that! You know that billing information is treated far more carefully than is their paysite username and password. That difference is, in fact, probably the basis of your hacker problem.

Even more difficult is discussing the security of your billing scripts. Every company considers them proprietary. Never mind the fact that you can find indexed copies in google, complete with master password. Nobody cares to admit to security holes. Especially when the admission carries the implication that credit card information might be no better cared for! We all know the credit cards are safe. We know the problem is that members area passwords are treated with less respect. But your members don't know that.

The hackers themselves will tell you that if you limit yourself (and anyone else on your server) to difficult passwords and better-secured billing scripts, they will have a difficult time indeed. They may even go broke because they can no longer charge their members for the chance to steal your bandwidth.

Additional Reading

1.Server Secrets. This article explains the unix/linux security hole and why it's necessary. If you ever struggled with permissions problems, this is the tutorial for you! (I have placed Server Secrets here as a separate article.)

2.A Tour of the Worm. The definitive article describing the full story behind the Internet Worm of 1988. It's actually interesting reading!

3.Murphy's Law. The original article is long since gone, “Murphy’s Law was Born Here,” perhaps because it has now been published as a book. It’s linked from the wiki page. The article is interesting reading and remarkably relevant: If something could possibly go wrong, you are responsible for assuming it will go wrong, and protecting yourself accordingly. (You must assume hackers will find a way to read files on your server. They will!)

4.Google. The number one piece of advice I see repeated on the hackers' forums is, Google is your friend. When you find a security hole, a google search will usually provide instructions on how to take advantage of it.

5.Google. If you're running mysite.com, for example, and your billing script is /cgi-bin/billing.cgi, try a google search for billing.cgi. You'll probably get complete instructions for exploiting the scripts, along with various vulnerable paysites.

6.Google again. For an eye opener, type username and password of mysite.com in the google search box. This little trick works darn near every time!