Keeping the Hackers Out: I Can Hack You, Part 4

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 and Linux 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 or Linux 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 plain-text 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 cryptography people do. No cryptographic 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 or Linux 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.