Archive for September, 2012

Billing Exploits: How to Hack a Paysite, Part 4

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! Read more…

The Buck Stops Nowhere: How To Hack a Paysite, Part 3

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. Read more…

Let’s Start Hacking: How to Hack a Paysite, Part 2

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! Read more…

Getting the Attitude: How to Hack a Paysite, Part 1

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 my 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. Read more…

The FastCGI Caveat: Web Server Secrets, Part 7

Many servers run their PHP and CGI scripts precisely as I describe above. That is, you and your script are two entirely different persons, so far as file ownership is concerned.

But… what if your script pretended to be you? Wouldn’t that simplify things? Of course it would. Never again do you have to worry about those subtleties of file ownership. What’s yours is yours, and what’s the script’s is yours too.

But… how does the script become you? That’s a very tricky thing to do in Unix or Linux. What’s important here, is for you to know when this is happening. Why is it important? Because it makes such a tremendous difference to how you set up your file permissions.

Okay, so you need to know if your scripts become you, or not. How do you find out? That’s easy – you ask your server admin. What’s difficult, is knowing what question to ask. There is no single correct question to ask! Like I said, this is a tricky issue in Unix and Linux, and therefore truly cool.

Ask Your Server Admin

Try asking the question this way: If I upload a file a file for my PHP or CGI script to edit, does the file need to have 644 permission, or 666 permission? Unfortunately, your admin might miss the point of the question. So, at the same time, ask this second question: If my CGI script creates a file, is that file owned by my ftp user id, or is it owned by the Apache server’s user id? If your admin has no idea what you’re asking, consider that a clue.

This bit of trickiness has a number of different names in Unix and Linux; the most common are SuExec and CGIWrapper. For PHP scripts, this is an option of FastCGI. All of these mean that your PHP or CGI script pretends to be you. Read more…

The Main Event: Web Server Secrets, Part 6

Let’s look back at the important points before we proceed to the main event. You’d be amazed at how many server admins don’t really understand the stuff you’re wading through here!

Interlude

For a PHP or CGI script to find, create, delete, or move files, the script needs suitable directory permission. This usually means that if the script is doing stuff in the directory, the directory permission needs to be set to 777. If stuff is mysteriously failing to happen, make sure the directory is where the script thinks it is, and that it’s set to 777.

For a CGI script to be treated as a script, the script itself needs execute permission, i.e., 755.

If a file needs to be updated (e.g., a data file), the file must be owned by the script, or have 666 permission. If a file needs to be created, it’s the directory which must have 777 permission. If the script creates the file, the script owns the file, so the actual file permission won’t be an issue (until we hit the main event!).

If you need to make all of your files and directories script-accessible, log into your server via telnet or ssh, and execute the following command: Read more…

The Problem of Script-Generated Files: Web Server Secrets, Part 5

Until now, everything works exactly as you’d expect. You create and upload your files; surfers surf them; all is well. Until, that is, you install a PHP or CGI script.

Still the Shared Departmental Thinking

Again, you need to think of your server as a shared departmental computer. Do you want your colleagues to be able to trash your files any time they have a mind to? Of course not. What about the ones who are not your colleagues? Do you want to allow anyone who has an account on that computer, to edit your personal files? Probably not.

On today’s servers, this might sound silly. Especially on a dedicated virtual server, where the only person there is you. On a shared server, security is tight. Most people are limited to ftp access, and they wouldn’t know how to find your files if they wanted to.

What’s important is the mind set. If you think like the departments did a generation ago, you’ll see what I’m getting at. Do you want the world at large to be able to overwrite your files?

Yes, actually, you do! Read more…

Apache Server Account: Web Server Secrets, Part 4

Each file or directory, then, has three permissions (rwx) each, for the file owner (user), group, and others. That’s why a Unix or Linux directory listing shows three sets of permissions:

• drwxrwxrwx for a directory, and
• -rwxrwxrwx for a plain file.

drwxr-xr-x 4 genealogist users 4096 Mar 30 19:24 .
drwx------ 5 genealogist users 4096 Mar 30 19:20 ..
drwx--x--x 2 genealogist users 4096 Mar 30 19:23 cgi-bin
-rw-r--r-- 1 genealogist users    8 Mar 30 19:21 .htaccess
-rw-r--r-- 1 genealogist users  747 Mar 30 19:21 index.html
-rw-r--r-- 1 genealogist users   32 Mar 30 19:23 main.html
drwxrwxrwx 2 genealogist users 4096 Mar 30 19:24 members

Three Digits

Unix is all about abbreviations. Vowels are never used when something unpronounceable will do. The first letter will often be used in lieu of the entire word. cp stands for copy, od stands for octal dump (but is what you use for hex dump as well), yes stands for you’re going to be sorry you asked. Read more…

File Permissions: Web Server Secrets, Part 3

This does not come anywhere close to being a complete explanation of Unix/Linux file permissions. We are only covering the basics you need to deal with your server!

Directory and rwx Permissions

Unix/Linux file permissions are Read, Write, and Execute, abbreviated r, w, and x. The lack of a certain type of permission is shown with a dash. So, rwx means read, write and execute permission, and rw- means read and write permission but not execute.

“Directory” means the same thing as “folder.” However, with Unix and Linux they’re always called directories. How do you know if it’s a directory or an ordinary file? On the file listing, there will be a d in the left margin just before the file permissions list. In the below example, I highlighted the directlry lines. The first three items are directories, and the last item is a directory. A dash means it’s a plain file. Anything other than d or – means your ftp program might get confused.

drwxr-xr-x 4 genealogist users 4096 Mar 30 19:24 .
drwx------ 5 genealogist users 4096 Mar 30 19:20 ..
drwx--x--x 2 genealogist users 4096 Mar 30 19:23 cgi-bin
-rw-r--r-- 1 genealogist users    8 Mar 30 19:21 .htaccess
-rw-r--r-- 1 genealogist users  747 Mar 30 19:21 index.html
-rw-r--r-- 1 genealogist users   32 Mar 30 19:23 main.html
drwxrwxrwx 2 genealogist users 4096 Mar 30 19:24 members

Unix and Linux directory permissions look the same as file permissions, but they are not the same! Directories have r, w, and x permission just like files… but r, w, and x don’t mean the same thing! Unfortunately, this means we need to look at r, w, and x one item at a time. Read more…

Technical Skills For Online Genealogy

Introducing the Genealogy Webmaster’s Journal aimed at explaining and advancing the technology underlying online genealogy.

Do the technical details of PHP/MySQL programming have any place on the Strong Genealogy Website? I could easily overrun our genealogy content with gruesomely technical material. This would arguably dilute our site’s focus and purpose.

Thinking through our collection process for genealogical information

I have come to realize that this site is NOT just about presenting the authoritative Strong Family History online. Rather, this is the online presence of the Strong Family Association of America. Let me explain the distinction!

Genealogy Web Site Becomes Social Online Presence

The SFAA (Strong Family Association of America, Inc.) is transforming itself from 20th-Century thinking to 21st-Century thinking. A major portion of that transformation is this here little ole Web site. One of our major purposes has always been social interaction. These days, much, if not most, social interaction takes place online. “Web site” does not equate to “social interaction.”

Our online presence, therefore, must include social interaction. We’ve been exploring ideas and ways to make that happen. The first step is correspondence and email. I’ll be updating our SFAA Web site to make that as obvious and easy as possible. In the webmaster world, that’s called making the process as “frictionless” as possible. Read more…