FTP Account Hacked... How did they guess the password?

Status
Not open for further replies.
G

Gerad

Guest
I manage a web server with a bunch of FTP accounts on it. One of them just got hacked and the site had javascript injected into it. The thing is that the password was ultra-secure. Does anyone have any idea how they got in? The server logged a valid user login in the FTP log.

Thanks for the help.
 


We manage a large number of FTP accounts for various clients, and occasionally find that one of them gets hacked into. Normally the cause is obvious, the client has an extremely poor password like "password" or "1234" which has been guessed by a bot. However, occasionally you get a break in where the passwords are secure, and realistically could not of be guessed by a bot without tripping a brute force alarm... Our best guess as to what is going on is that the webmaster's PC is infected with some sort of malware. There are a bunch of malware programs out there which are designed to steal FTP login credentials and send them to a remote servers. Then, this server will inject the victims website's with whatever payload it wants. Possible javascript, or hidden iframes pointing to malicious websites, or worse...

I would guess that this is what is going on in your case, especially if it keeps happening to the same account over and over again.

If that isn't it. I would make sure that you have brute force logging/protection. And also consider rate limiting your FTP login attempts with iptables/chains or some sort of software/firewall package.

Good luck!
 
scp is the most secure transfer method, in my opinion. You can enable security keys and a passphrase. I don't use FTP because of the security implications of it.
 
They might not of "guessed" the password. The owner of the FTP account might of been compromised, possibly key logged and the password stolen, rather than guessed.

You can't just assume the obvious.
 
They might not of "guessed" the password. The owner of the FTP account might of been compromised, possibly key logged and the password stolen, rather than guessed.

You can't just assume the obvious.

This is true, also. Again, it comes back to the reason I use SCP. Getting your hands on the Key AND the Password are difficult enough, and if the hacker managed to get all that information and get in....well, maybe you should consider posting a "Security Admin for Hire" job posting on your server for next time he gets in :)
 
This is true, also. Again, it comes back to the reason I use SCP. Getting your hands on the Key AND the Password are difficult enough, and if the hacker managed to get all that information and get in....well, maybe you should consider posting a "Security Admin for Hire" job posting on your server for next time he gets in :)

Yeah. I find the best method is to just lock down services to your IP (if IP is static), gives you ultimate secure.
 
Yeah. I find the best method is to just lock down services to your IP (if IP is static), gives you ultimate secure.

This can be very bad if you need to access the server remotely, or you are not at home. The only way to do this, and ensure you'll be able to access your server anytime you need to, would be to set up a VPN for when you are away from the primary (static) computer. Another problem you run into is if the ip address changes, you have to figure out a way to update your server to reflect it so you are not locked out.
 
I heard filezilla never encrypted the password so I think its the reason.
 
It's always better to have your FTP logins run through SFTP or FTPS. SFTP creates a connection via SSH and gives you access to your files which is very very safe to use.

FTPs on the other hand would require an SSL certificate or SSL connection, mostly TLS/SSL. I don't know how safe a self signed certificate is but i still think it's better than sending the password as clear text.

Also try to form stronger passwords for your FTP accounts.
 
FTPs on the other hand would require an SSL certificate or SSL connection, mostly TLS/SSL. I don't know how safe a self signed certificate is but i still think it's better than sending the password as clear text.

When you buy a certificate from say, VeriSign or GoDaddy, its self-signed there. The only difference is that when you buy from a valid vendor, there's a bit of information they leave into the certificate so systems know who its from (usually in a field for SSL certificates). This really is the only difference between "self-signed" and "non-self-signed" certificates. They both function the same. I personally prefer self-signed certs because you can use a higher bit-length of encryption (i.e.: 1024 instead of 512).
 
When you buy a certificate from say, VeriSign or GoDaddy, its self-signed there. The only difference is that when you buy from a valid vendor, there's a bit of information they leave into the certificate so systems know who its from (usually in a field for SSL certificates). This really is the only difference between "self-signed" and "non-self-signed" certificates. They both function the same. I personally prefer self-signed certs because you can use a higher bit-length of encryption (i.e.: 1024 instead of 512).

Oh okay, thank you for that. I am using a normal Positive SSL certificate by Comodo provided by Namecheap. It's probably self-signed by Comodo cause i don't see a certification path from namecheap. The main provider might be USERtrust. They provide a 256 bit encryption.

It should be good enough i'm guessing.

Anyways i'm guessing that your FTP is secure by now :)
 
Oh okay, thank you for that. I am using a normal Positive SSL certificate by Comodo provided by Namecheap. It's probably self-signed by Comodo cause i don't see a certification path from namecheap. The main provider might be USERtrust. They provide a 256 bit encryption.

It should be good enough i'm guessing.

Anyways i'm guessing that your FTP is secure by now :)

Mine? No, lol. I don't use FTP. I use key authentication for SSH. However, Comodo is a verified SSL certificate vendor (CA; certificate authority), and Namecheap is just a reseller for Comodo, so you're still good. OpenSSL has a SSL certificate information program where it displays various information about a cert. Can read more on it here: http://www.openssl.org/docs/apps/x509.html#DISPLAY_OPTIONS (most likely it'd be openssl -in <cert file> -text but I'm not completely sure...never used it before myself, I just know it exists).
 
Mine? No, lol. I don't use FTP. I use key authentication for SSH. However, Comodo is a verified SSL certificate vendor (CA; certificate authority), and Namecheap is just a reseller for Comodo, so you're still good. OpenSSL has a SSL certificate information program where it displays various information about a cert. Can read more on it here: http://www.openssl.org/docs/apps/x509.html#DISPLAY_OPTIONS (most likely it'd be openssl -in <cert file> -text but I'm not completely sure...never used it before myself, I just know it exists).


Oh sorry i had mistaken you for the Creator of this Topic xD, my bad.

Thanks for that link, i didn't know about the x509 utitlity to get the outputs of the certificates and issuer information . I'll stick with Comodo since i just need it for the login pages.
 
Oh sorry i had mistaken you for the Creator of this Topic xD, my bad.

Thanks for that link, i didn't know about the x509 utitlity to get the outputs of the certificates and issuer information . I'll stick with Comodo since i just need it for the login pages.

Hah, its alright. :) Welcome for the link. If you want to investigate any of your certificates (see where they're from, what info is in it, etc...) its a cool tool to use. Mostly for investigation and curing curiosity lol.
 
Sorry to hear of the compromise... It's a bad feeling, and I myself have a very hard time trusting a machine that has been compromised anymore.

Anyway, K.I.S.S. The simplest way for an attacker to gain access is by attacking the client machine, or intercept data (in some way: keystroke logger, sniffer on the client, etc.) from the client machine or the person using the client machine. In the case of a keystroke logger, it would not matter how secure the protocol or app is, the logger would still get the password.

On the server side: limit which IPs can access the service (even if the attacker has the pw, they can't get to the service without using an authorized client); enforce strong passwords (as it seems you are already doing - kudos, that's a tough one); encourage updated virus and malware protection; encourage an environment of security so it is in the forefront of the users' minds. And hope that what you do is enough.

Good luck!
 
Don't need to guess the password if you catch the packet
 
You are only as secure as your weakest link. You cannot rely on the security of your client accounts for the security of your site.
 
You are only as secure as your weakest link. You cannot rely on the security of your client accounts for the security of your site.

Amen, brother. But, unfortunately, the clients are a reality that we have to deal with. The best we can do is minimize the exposure and try to educate the users to practice safe computing. Sometimes, though, that's like forcing a square peg in a round hole.
 
They might not of "guessed" the password. The owner of the FTP account might of been compromised, possibly key logged and the password stolen, rather than guessed.

You can't just assume the obvious.
Hi, Mustang.
This person is an admin, and probably thought and searched long and hard for the invader. I don't think they are assuming the obvious here.
 
I manage a web server with a bunch of FTP accounts on it. One of them just got hacked and the site had javascript injected into it. The thing is that the password was ultra-secure. Does anyone have any idea how they got in? The server logged a valid user login in the FTP log.

Thanks for the help.

Hi, Gawood,

The hacker may have been one of the world's best. Here's a really helpful book on how a super/superuser got hacked, and how he caught him. Really, it's amazing the methods that can be used....

Takedown: The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw - By the Man Who Did It by Tsotomo Shimomura & John Markoff
 
Status
Not open for further replies.

Members online


Top