msgbartop
Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
msgbarbottom
Loading site search ...

FTP Brute Force Attacks?

   26 Jun 13   Filed in Website exploits

Hacking websites using FTP access has been one of the most popular attack vectors during the last few year. I can still see many massive site infections done via FTP.

In most cases, the first step of such attacks is stealing FTP credentials from local computers of webmasters. Back in 2009, I described how PC malware stole passwords saved in popular FTP clients such as FileZilla, CuteFTP, SmartFTP and many more. This is still a prevailing vector. More exotic password theft methods include keyloggers, FTP traffic sniffing, and stealing user databases of hosting providers who prefer convenience over security and store actual client passwords in plain text or slightly encrypted (instead of storing only hashes of passwords).

If you ask regular webmasters how hackers can break into their server via FTP, many of them will answer that hackers could guess the password (hence the need to have hard-to-guess passwords). Of course, it is hard to guess whatever password at the first attempt, so one might expect to see multiple such attempts (so-called brute force attacks) before a password is cracked and hackers get access to a server. However in real life, I haven’t come across such FTP brute force attacks. Until this month…

FTP log analysis

I helped a webmaster of a hacked site and, as always, requested recent access and FTP logs to figure out how the site was hacked. The FTP logs clearly showed that someone used a valid username and passwords to upload infected files to the server. This happened several times a day (constant reinfections) from different IPs in different countries. Quite a typical picture.

What was untypical were requests that looked like a brute force attack. They came from different IPs and each IP tried to login using many invalid usernames.

Choice of usernames in brute force attacks.

Here are just a few such sessions and the usernames they tried.

198.50.144.128 (Canada Montreal Ovh Hosting Inc) – 165 login attempts within 70 seconds.

second_level_domain
second_level_doma
webmaster

where <second_level_domain> should be replaced with a real second level domain of a site. E.g. in case of “example.com” the second_level_domain will be example.

This attack used the <domain name> as a username and webmaster as an alternative (supposedly default) username, and tried multiple popular passwords from some dictionary.

46.29.255.84 (United States Lombard Deepak Mehta Fie) – 9 login attempts at a rate of 2 a second:

second_level_domain
second_level_domainsecond_level_domain
second_level_domainftp
second_level_domainroot
second_level_domainadmin
second_level_domainuser

In this case, the attacker used domain name derivatives (appending words like ftp, admin, user) as usernames, and the passwords probably matched the usernames (e.g. exampleftp/exampleftp). A few times they re-tried the same usernames. Probably with slightly different passwords.

110.85.113.113, 110.86.165.187, 117.26.118.189, 117.26.119.68 (all from China Fuzhou Chinanet Fujian Province Network) — 76 login attempts in less than 5 minutes from 4 IPs.

000000
111111
112233
123
123321
123456
12345678
123456789
123654
123abc
147258
147369
222222
321123
333333
444444
5201314
521521
555555
666666
777777
888888
987654321
999999
abc123
admin
admin111
admin123
admin222
admin321
admin333
admin444
admin555
admin666
admin777
admin888
admin999
asd123
asdasd
second_level_domain
second_level_domaintop_level_domain
data123
qwe123
qwerty
test
web
web123
www
www123
zxc123
zxcvbn

Distributed attack

The last one was obviously a distributed brute force attack where bots from 4 different IPs worked simultaneously and in sync. E.g. one checked “111111” then another checked “112233“, then third checked “222222” and “333333“, then fourth checked “444444“, and so on. Most likely this attack also assumed that some sites may use the same words both as a username and a password.

The above three attack took place within 26 hours. Each of them used different approach to choosing usernames and passwords, and they came from different parts of the Internet. It means that there is a real interest in FTP brute force attacks among cyber criminals.

Why didn’t I come across such attacks before?

After all, brute-force attacks on WordPress and Joomla admin interfaces proved to be very efficient. What makes them so efficient is the fact that there are many millions of WP and Joomla sites out there, and out of those millions there will always be enough sites whose admins were thoughtless enough to choose weak passwords. That’s why I see hundreds or even thousands of login attempts per day in access logs of almost every WordPress and Joomla site I work with. And unfortunately, some of those site were hacked as a results of the brute force attacks.

One might think that FTP is an even better target for brute force attacks since almost every site has FTP access so the number of victims with weak FTP passwords should be substantially larger than the number of WP an Joomla sites with crackable passwords. However it’s not that easy. You should not forget than in case of WP and Joomla, hackers assume that site administrators use the CMS default usernames (admin for WP and administrator for Joomla) so they only need to guess their passwords. But in case of FTP, the username is not known. There is no default FTP username. This is especially true for shared hosting environments where every client must use a unique username. So you need to guess both username and password in order to get access to a site, which dramatically reduces efficiency of brute force attacks (don’t forget the network latency of each FTP request which prevents from testing millions of variants per seconds that one might expect in a latency-free environment).

In order to try the brute force approach, hackers need to narrow down their attack to the simplest cases and hope that the Internet is so big that even a tiny fraction of sites with hackable FTP credentials will worth the effort. And the Internet is really big (there are more than 100,000,000 .com domains alone) and to have better results one needs to attacks as many of them as possible, so the set of username/password pairs should be kept as tight as possible to provide results in reasonable time. Based on the above FTP log analysis, the current approach is to target:

  • sites that use their domain name or some easy derivative from a domain name as a username along with a weak password.
  • sites that use the same simple words for both usernames and passwords.

Another reason why FTP brute-force attacks are not popular is the FTP logins can be tracked by server administrators who can, for example limit number of consecutive failed login attempts per IP address and then block the offending IPs (for example, using the fail2ban tool).

I also guess that many server and client bots might simply lack the FTP brute force functionality…

Do you have any better explanation?

Why did I see the FTP brute force attacks on that particular site?

I have two hypothesis:

1. Massive FTP brute force attacks are in the proof of concept stage. A few years ago WordPress brute force attacks were quite rare too, but once criminals figured out that they could be very successful if you had enough resources to attack a large number of site, such attacks went mainstream. So maybe if FTP brute force attacks eventually prove to deliver good results, we’ll see a flood of login attempts in FTP logs of most sites (I hope not).

2. In the beginning of the post, I forgot to mention about one more failed login attempt. It used the “anonymous” username and the 66.249.72.181 IP address. The thing is the IP address belongs to Google, more specifically to Googlebot. This means that there are some FTP links (e.g. ftp://example.com ) to that site on the web and Googlebot tries to crawl them using the default anonymous username which normally doesn’t require a password and is used for public FTP sites. Here is the explanation from John Mueller (Webmaster Trends Analyst at Google):

When we find links to FTP content, we’ll generally attempt to crawl those URLs. If they’re publicly accessible and return normal content, we may choose to index them as well. While it’s not that common, there are occasionally queries where a file on an FTP server is a good result.

So my guess is such attacks may be limited to the sites that have direct FTP links to them on the web.

Do you have any better explanation?

Just in case. No, the original successful FTP hack that I investigated was not a result of a brute force attack. The username was not obvious and the password was strong. The attackers used the tried-and-true credential theft approach.

To webmasters

Regardless of the chances to see massive FTP brute force attacks in future, the described example should be considered as yet another lesson to all webmasters, who should realize all risks associated with FTP.

  1. Carefully choose both username and password.
    • They should not be the same
    • The username shoudn’t be easy to guess (e.g. your site domain name is not the best choice)
    • The password should be strong.
  2. Don’t save passwords in FTP programs. Configure them so that they ask for a password every time you connect to your site. If you work with multiple sites and/or don’t like the idea of memorizing many passwords, consider using password managers like KeePass or LastPass — they save your passwords much more securely.
  3. Consider using SFTP instead of FTP that sends your passwords in plain text (they can be easily intercepted, for example, when you use public Wi-Fi). Most popular FTP programs support SFTP, so the switch should be painless. If you manage your own server, consider not installing an FTP server altogether (or uninstalling it now if there are no others users who can’t use SFTP).
  4. If you manage a server, consider blocking multiple consecutive failed login attempts at a firewall level (tools like fail2ban may help). Moving FTP to a custom port may also help.
  5. Minimize risks of infecting your local computer (which brings you a step closer to password theft). Make sure that all software on your computer is up-to-date. This includes all OS security updates, all browser updates and all browser plugin updates. Here you can check whether your browser is vulnerable:

Related posts:



Comments are closed.