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!
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 PHP and 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
Web 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!
A Tour of the Worm. The definitive article describing the full story behind the Internet Worm of 1988. It’s actually interesting reading!
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!)
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.
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.
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!