iframe / javascript hacks?

[jack01]

One of the reasons why this is occurring could be because, the users specify their main cpanel username/password for accessing databases of php applications. Once phpshell is uploaded into the server, we can easily retrieve such passwords. But I have seen this occur on accounts which do not use the main cpanel username/password for accessing the mysql databases.

I can confirm that this hack occurs on most accounts which have ftp/cpanel passwords that are diffrerent to MySQL user passwords. In fact this hack has occurred even on acccounts not using PHP or MySQL at all.

Yes, this really is a serious problem; has anyone submitted a cpanel ticket on this issue since JamesSmith tried (ref. earlier posts in this thread)?

[brianoz]

I can confirm that this hack occurs on most accounts which have ftp/cpanel passwords that are diffrerent to MySQL user passwords. In fact this hack has occurred even on acccounts not using PHP or MySQL at all.

There's another possible cause - weak passwords. Did the compromised accounts have weak passwords?

Does a grep through the logs for those IPs reveal any other sort of intrusion attempt? ie in http logs etc?

[jack01]

brianoz,

In a previous post amal stated:

1) It happens to a wide range of accounts. It happens on more than one server with different passwords as the root passwords.
2) Only method of hack used is ftp.
3) The hacked accounts do not fall under any specific resellers
4) Pure-ftpd, cpanel, kernel php, apache are all updated to their latest versions on the server being hacked.
5) No unauthorized root logins.
6) FTP Access to different accounts from the same ip. Once we block the ip, the hack continues from a different ip after a couple of days.
7) FTP Login in the very first attempt. no Brute force attempts.
8) For the hacker ip, No other logs other than /var/log/messages ( ftp logs ), and domlogs ( only ftp logs ). No trace in cpanel access logs or on any other logs.
9) A sample source ip of this kind of hack is 84.16.230.108
10) This happens for accounts with strong passwords as well.

I basically concur with all this, in particular note point 8 above. The FTP passwords range from weak to very strong, I can't see weak passwords being the actual problem here.

[brianoz]

Please don't take it as myself implying anyone's stupid here; we just have to make sure to cover all the bases very thoroughly to have a chance of tracking this thing down, which includes eliminating carefully all the known possible causes.

Did Amal say whether the box was phpsuexec/suexec?

That would also be interesting. For instance, even in the absence of mysql passwords in readable php files, mail passwords could be the same as cpanel passwords, the mail password files could be taken offline and password cracked, hence why I'm asking this level of detail of question. I know it's a long shot, but it is possible, and until it's eliminated as a possibility it's more likely than an unknown security hole. Quite likely the mail password files would have been harvested a month or more before the incident to hide from logs.

Did these accounts have email accounts? Could those have had weak passwords?

ps: sorry about missing point 8 above, it's late here, I need sleep

[brianoz]

Tell 500 users they need to use a new ftp port? You're kidding right? This isn't a fix, it's a bandaid. FTP ports need to stay as they are.

[easyhoster1]

Again, your config files are your friend.

Change the FTP port/ and or ip in your config. Just make sure to open the new port in your firewall if you have one before you do this.

# IP address/port to listen to (default=all IP and port 21).

# Bind 127.0.0.1,21

Make sure to uncomment the line and restart your FTP server.

Then let your trusted users know of the change.

[jack01]

Easyhoster1,

In principle you may be right about making it harder for FTP hackers to find the FTP port, however it is by no means a proper remedy to the problem (I'm not suggesting that you think so, just making the point).

And not to speak of the nightmarish client support issues this will inevitably generate (this kind of changeover is no fun with thousands of users).

[easyhoster1]

Tell 500 users they need to use a new ftp port? You're kidding right? This isn't a fix, it's a bandaid. FTP ports need to stay as they are.

Well, as they say...Its not a matter of IF you get hacked, but WHEN! None of our servers are ever setup with default ports. You just need to educate your users as your looking out for their security and they will appriciate it.

Best of luck.

[easyhoster1]

Easyhoster1,

In principle you may be right about making it harder for FTP hackers to find the FTP port, however it is by no means a proper remedy to the problem (I'm not suggesting that you think so, just making the point).

And not to speak of the nightmarish client support issues this will inevitably generate (this kind of changeover is no fun with thousands of users).

True, but its just amazing how many people still use port 22 for ssh. Our servers with default ports changes have seen probes declined by 99%. That is a fact.

[elma]

I'll mention a few interesting characteristics of this hack...

1) It happens to a wide range of accounts. It happens on more than one server with different passwords as the root passwords.
2) Only method of hack used is ftp.
3) The hacked accounts do not fall under any specific resellers
4) Pure-ftpd, cpanel, kernel php, apache are all updated to their latest versions on the server being hacked.
5) No unauthorized root logins.
6) FTP Access to different accounts from the same ip. Once we block the ip, the hack continues from a different ip after a couple of days.
7) FTP Login in the very first attempt. no Brute force attempts.
8) For the hacker ip, No other logs other than /var/log/messages ( ftp logs ), and domlogs ( only ftp logs ). No trace in cpanel access logs or on any other logs.
9) A sample source ip of this kind of hack is 84.16.230.108
10) This happens for accounts with strong passwords as well.

exactly same

I'm pretty sure its automated because after downloading the file, it looks for header tag, if it cant find it (my index.php requires other php files), appends the iframe to the end of the file. I have added exit(); at the end of my index.php and it kinda worked. Than i have completely disabled FTP server and haven't attacked since.

[MN-Robert]

Tried switching to proftpd?

Maybe the issue lies with the pureftpd?

[JamesSmith]

Tried switching to proftpd?

Maybe the issue lies with the pureftpd?

No, the issue is with both ProFTPd and pureftpd.

At first we thought it may have been a ProFTPd problem so switched those that were running ProFTPd over to pureftpd, but the problem persisted.

[daveformerlyof]

cPHulk may be a good solution to this if it's cause by weak passwords. It's in cPanel 11. cPHulk allows you to set authentication thresholds per account or per IP for any service using PAM (FTP, SSH, cPanel, WHM, IMAP, POP). That way, after say 5 failed password attempts, the account will be locked for a set number of minutes (invisible lock to the attacker, they can keep trying to authenticate). Further attempts after a lock out can be set to increase the lockout time as well.

[jack01]

Nice feature, but not really an issue here - we have already established that either (i.e. both) weak or strong passwords are used for the hack.

[daveformerlyof]

Nice feature, but not really an issue here - we have already established that either (i.e. both) weak or strong passwords are used for the hack.

Anyone have some info about what they think is the cause / hole? I haven't seen anything sent to security AT cpanel.net about this even though there's a five page thread here. Remember, we can't and don't read every thread on the forums.