Protecting FTP Passwords from Brute Force Attacks
"Always use strong passwords." - You probably don't pay too much attention to this advice, do you? A lot of people don't either. That's why brute force is still one of the favorite techniques for breaking into any password-protected system, including FTP servers. It's really not very difficult to carry out. Let me show you.
What is a brute force attack?
The basic principle behind a brute force attack is very simple. Have you tried testing a kid who's just started learning math? If he thinks the answer is somewhere say between 2 and 7 but doesn't know exactly what it is, he may resort to guessing: "Is the answer 4?", "5?", "6?", "3?" ... until he gets the correct answer. It's not the right way to do math, but sometimes he'd be able to get the answer anyway.
A brute force attack is like that. It's a way of cracking passwords by guessing. But these "guesses", delivered one after another, are done very rapidly. They are spewed forth by hacking tools that reference a really long list of possible passwords, often called a wordlist.
By the way, these tools are mostly free. And while they're not exactly what you might normally call kid stuff, kids are already using them to hack into government offices. If a bored kid would like to hack into your FTP server, he can do so with relative ease.
I'm no kid. But if I were one, this is how I would hack into yours.
A simple brute force attack
1. Scan your network
The first thing I would do is use a security scanner like nmap to discover what hosts you may have on your network and what open ports/services those hosts might in turn have. Let's assume I know that your network is identified as 10.0.0.0. After scanning, I discover that a host or server in your network identified as 10.0.0.4 has an open FTP port (21).
If nmap tells me a port is open, that means it's hackable.
2. Acquire more information
The next thing I would do would be to obtain as much information as I can about the people who use your FTP service. Obviously, before I can start guessing passwords, I would need to get a hold of some usernames. If I can obtain the real names of your users, that can turn out to be valuable information.
You see, some network admins who assign the usernames themselves derive these usernames from the users' real names. One common technique applied by admins is to take the first letter of a user's firstname and append it to the surname. For example, if a user is named Michael Guy, then the admin would assign him the username 'mguy'.
Some organizations also use email addresses as usernames (a very common practice online). So if you follow some kind of "formula" when creating usernames and I am able to get hold of that formula, then it will make my job easier.
Clearly, someone already familiar with the internal practices of your organization can potentially be a vital source of information or possibly become a potent hacker himself. If I were an adventurous employee or a disgruntled ex-employee, I would be in a very good position to carry out this kind of attack.
Read more about threats within your organization by clicking this link.
After obtaining some user information, I would then set out to generate a list of possible passwords. Yes, sometimes I would have to generate usernames as well. But as I've explained recently, it's often possible to determine or make educated guesses of usernames without the aid of any hacking tool. So for this post, let's just assume I know the username of the FTP account I want to hack. Let's say it's 'mguy'.
Next up, how I would generate a password list.
3. Generate a password list
There are several tools you can use to generate a wordlist. For this post, I'll be using crunch, a simple terminal-based tool. To run crunch, I would need to specify the password length (the number of characters in the password) and, optionally, the file the wordlist would be written to. In my case, that file would be passwords.txt. Crunch has other options but we won't be discussing them here.
Here's a typical crunch command in one of its basic forms:
I intentionally issued the crunch command four times just to show you how the password length greatly affects the size of the resulting wordlist file. The password lengths I used for each command execution were 2, 3, 4, and 5, respectively.
As you can see, a wordlist consisting of only two (2) characters per password would result in a 2,028-byte file, while a wordlist of 5 characters per password would already result in approximately 71,000,000 bytes (71 MB).
A 6-character wordlist file, which I haven't shown here, would required about 2 GB of storage space.
I have only used the default character set, which only consists of all lowercase letters in the English alphabet. Meaning, all words in my list will only have lowercase letters from a to z. Once I start including uppercase letters, numbers, and/or other non-alphanumeric characters in my character set, that size would grow considerably larger.
A wordlist of 3-character words consisting of lowercase letters
How large? Well, a wordlist file of 6-character passwords consisting of all alphanumeric characters (lowercase and uppercase) plus a set of non-alphanumeric characters would result in over 1 Terabyte of disk space. But that's not all. Such a wordlist would take a great deal of time to generate. And then once that massive list is fed to a password cracking tool, it would again consume a considerable amount of time.
In other words, it would be more computationally expensive and time consuming on my part to crack longer and more complex passwords.
Let's now proceed to the interesting part of this discussion - breaking into the server.
4. Conducting the brute force attack
To conduct my brute force attack I would need a tool like THC Hydra. This tool will connect to the FTP server, read from the wordlist file, pick the first word in the list, and then submit that as the password. If the login fails, it picks the second word and then submits again. It repeats this process over and over until the right password is submitted and the login succeeds.
Here's the screen where I enter the target's IP address (10.0.0.4), port number (21), and protocol (FTP):
Here's where I enter the username (mguy) and the path of the wordlist file. Notice that I could also enter a path for another wordlist file into the Username List field. In other words, if I didn't have a target username, I could have used the same tool (crunch) to generate a separate list for usernames and then fed that list here.
Here are the first few login attempts as seen from Hydra:
Finally, this is what I'll see after a long wait.
Had I used a wordlist file for my usernames, I might have been able to obtain multiple username-password pairs.
It's actually easier than it looks. Like I said, a bored kid can do this.
So now that you know how a hacker can break into your FTP server using a brute force attack, it's time to learn how to counter it.
Countering brute force attacks on your FTP server
First, I'd like you to think like a hacker. A hacker would always aim for your weak points. That's why your FTP service, being practically devoid of any strong security feature, will make you a sitting duck. But there's still something you can do about it.
To turn the tables around, you'll have to aim at the attack's weakest points. Incidentally, a brute force attack has a couple of characteristics that you can use to your advantage:
1. It makes a lot of noise. Meaning, it's easy to detect, and
2. It requires a lot of computational resources (e.g. storage and CPU) to crack strong passwords.
Let's have a look at my FTP server's logs in the middle of a brute force attack.
Those are failed login attempts and you'll see a lot of those whenever your server's subjected to a brute force attack. There are a couple of things you can do to take advantage of this particular characteristic.
You can limit the number of times a user account or an IP address can login. You can configure your server so that once the limit is reached, it will automatically block further attempts from the same account or IP address.
On JSCAPE MFT Server, this can be implemented in the Connections node. This setting will allow you to disable a user or an IP address (or both) after it has made a certain number of invalid password attempts within a certain duration (e.g. 3 minutes). You can then specify how many minutes the account or IP should be blocked.
This is what appeared on my server logs after I implemented the "Disable IP after..." policy.
And then this is what I got on Hydra:
Use this countermeasure with caution. Attackers can take advantage of this setting to launch a Denial of Service (DoS) attack, which can be done by conducting fake brute force attacks that would cause accounts to be blocked and prevent legitimate users from logging in.
Of course, the other defense against brute force attacks is the one you saw when you started reading this blog post: implementing strong passwords. The longer and the more complex passwords are, the more difficult it will be for a brute force attack to succeed. The attacks will require more powerful machines and much larger storage spaces. That would certainly put kids and non-funded hackers out of the equation.
But how can you effectively enforce a "strong password" policy? Surely you can't simply rely on users to voluntarily include numbers and non-alphanumeric characters in their passwords.
Well, in the JSCAPE managed file transfer server, you can actually impose certain password rules that would allow the server to automatically deny login in the event of a non-compliance. You can set these rules in the Compliance module.
As you can see, you can require uppercase and lowercase letters, numbers, and non alphanumeric characters.
Brute force is one of the most commonly used attacks for breaking into FTP servers. You can counter it by providing your FTP service via JSCAPE MFT Server, which supports enough security countermeasures that can thwart this type of attacks. Please note that FTP passwords can also be compromised using other tools like packet sniffers. A much better solution would be to avoid FTP altogether and use more secure file transfer protocols like FTPS or SFTP instead. JSCAPE's managed file transfer server also supports these two secure protocols and more.
Download JSCAPE MFT Server
Download JSCAPE MFT Monitor