Advanced Cracking: I Can Hack You, Part 2
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 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.
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.