iframe / javascript hacks?

[gorilla]

i just searched all my index.* in public_html
egrep iframe /home/*/public_html/index.*

just to get a quick return to see if any looked nasty and only got a few hits across 8 boxes and all were ligit iframes. So far so good for me ..knock on wood

thats great to hear, although the trustdot iframe exploit is an older issue and we especially experienced the javascript exploit

grep -l 'JavaScript>function dc' /home/*/public_html/index.htm
grep -l 'JavaScript>function dc' /home/*/public_html/index.html
grep -l 'JavaScript>function dc' /home/*/public_html/index.php

unfortunatly this one not only modifies the index pages but all other pages as well



Since the last issue regarding this exploit (back in march) we also installed suhosin and are forcing everybody to use the SSL cpanel ports as well, we even enabled the modsecurity IP block in CSF .

Regarding password simplicity ;
Resellers are the only ones who can nominated their own passwords, but unfortunatly cPanel still hasnt enforced a more secure password creation method to force the enduser to use at least an 8 letter and number combo like plesk has got.

[rpmws]

thats great to hear, although the trustdot iframe exploit is an older issue and we especially experienced the javascript exploit

grep -l 'JavaScript>function dc' /home/*/public_html/index.htm
grep -l 'JavaScript>function dc' /home/*/public_html/index.html
grep -l 'JavaScript>function dc' /home/*/public_html/index.php

unfortunatly this one not only modifies the index pages but all other pages as well



Since the last issue regarding this exploit (back in march) we also installed suhosin and are forcing everybody to use the SSL cpanel ports as well, we even enabled the modsecurity IP block in CSF .

Regarding password simplicity ;
Resellers are the only ones who can nominated their own passwords, but unfortunatly cPanel still hasnt enforced a more secure password creation method to force the enduser to use at least an 8 letter and number combo like plesk has got.

thanks for the grep search keys

I am going to ask Nick to build in a random password generator button on the account creation page. Stil lwon't stop people from putting in their own

If we wrote a script to hit all of our usernames with the password "password". I wonder what the ratio would be. I found 2 users using "password" for the password

[rpmws]

i just ran this:

grep -l 'JavaScript>function dc' /home/*/public_html/index.*

on all my boxes and came up clean so far so good. But that's less than 2000 domains so my exposure I am sure is small compared to some of you guys. It's got me worried. I hope we can figure this out.

[easyhoster1]

I belive the exploit is from the ProFTP hole that I posted above. Even though we use PURE-FTP for our FTP server and are not effected as we change the default port.

If anyone notices, when they remove any account from a server the domains info is removed from PROFTP....Both FTP programs use PROFTP.

Again, this server is running Pure-FTP

Just removed an account from one server.

Removed Entry from proftpd.conf

Removing localdomains entires....Done
Adding ip back to ipaddrpool....Done
Removing Control Panel file....Done
Removing Stats Run Information....Done
Removing Proftpd File....Done

Seems to share the configs from what I see.

[rpmws]

I belive the exploit is from the ProFTP hole that I posted above. Even though we use PURE-FTP for our FTP server and are not effected as we change the default port.

If anyone notices, when they remove any account from a server the domains info is removed from PROFTP....Both FTP programs use PROFTP.

Again, this server is running Pure-FTP

Just removed an account from one server.

Removed Entry from proftpd.conf

Removing localdomains entires....Done
Adding ip back to ipaddrpool....Done
Removing Control Panel file....Done
Removing Stats Run Information....Done
Removing Proftpd File....Done

Seems to share the configs from what I see.

That still doesn't explain how the attacker simply ftp's into the server and does his thing. He is passing the correct username and password. If the password is changed ..he can't get in. I really really think its plain text account login details somewhere.

Has anyone confirmed that any of the hacked accounts that were hit using the FTP login/logout were brand new domains that were using newly created strong passwords? If anyone can confirm that some of these are new then it might smack my theory of an old billing system list that someone got into.

[easyhoster1]

That still doesn't explain how the attacker simply ftp's into the server and does his thing. He is passing the correct username and password. If the password is changed ..he can't get in. I really really think its plain text account login details somewhere.

Has anyone confirmed that any of the hacked accounts that were hit using the FTP login/logout were brand new domains that were using newly created strong passwords? If anyone can confirm that some of these are new then it might smack my theory of an old billing system list that someone got into.

Sure it does;

"The Auth API in ProFTPD before 20070417, when multiple simultaneous authentication modules are configured, does not require that the module that checks authentication is the same as the module that retrieves authentication data, which might allow remote attackers to bypass authentication, as demonstrated by use of SQLAuthTypes Plaintext in mod_sql, with data retrieved from /etc/passwd"

Just like SSH probes, they multi connect to port 21 using a sniffer. This is one reason why I suggested limiting multiple connections from the same IP in the config. The probes will be denied and help from boxes from becoming rooted. Just keep an eye on /var/log/messages and the log file will be full of FTP failures eventually if you enabled the limited connections.

Go back to page nine for the refrence links I posted. There is a patch for this.

Go back to page 4 and see Frankc probes with the multiple connections. Denying multiple connections may not be a fix, but it will help stop them getting in and adds just another extra layer of security.

[jerrek71]

I think yours sounds like the old old RVSkin issue. Do you use RVSkin? or did you?

Hi,
Yes, I use RVSkin, and when I questioned if this might be the case the RVSkin author came on here and pretty much denied there was any problem with RVSkin...

Why hacker bother to upload file through cPanel File Manager despite he get the cPanel username and password. Ability to FTP to the server can do a lot damage than hacking through cPanel interface. It must have a reason behind it. Is it possible that one of your reseller has a weak password and got hack? And hacker know you are using cPanel, so they just browse to cPanel accounts using reseller password and jump around to other accounts.

Since no-one else at that time said 'that sounds like the old rvskin problem' I concluded that RVSkin was not the issue... However, from what you're (rpmws) saying, there is in fact an RVSkin issue... Is there a fix for it - and do I need to get all my customers to change their passwords now?

Thanks for your help rpmws - it is very much appreciated!

Regards,
Steve

[k1k]

Hi all,

I am tired of "hacked ftp", "hacked file manager" ... updates. I have detected the same issue on some of my servers and I have found that there are no changed files in the home folders. I have backups and MD5 . There is not difference between the old and the new files. Yes the attacker can change your files, but he/she is smart, because we will restore the file from our backups. So that is not a solution for him/her. That's why we have another option - memory poisoning. If you do not believe me then you will see that there are many different pages(you can see it in every php.script or when you load a simple index file that you have just written) , infected with the same java code. So the code is not loaded from the drive.
I have tried the grsecurity patch on my machines and the problem disappeared . It seems that the memory protection options in it are working properly.
All the servers with RH EL4 default kernels are vulnerable, but the RH team has not updated it yet. I am afraid that we will have to do that alone. If you have any ideas or suggestions then it would be cool if we can discuss them here, but please FORGET THE CHANGED FILE idea.

K.Kossev

[jack01]

but please FORGET THE CHANGED FILE idea

k1k, I am not going to forget the 'changed file idea' as you put it because THAT is the issue I, and several others are actually having and we have been discussing it in this thread. Just because that is not the specific issue affecting you does not mean it is not happening to others.

Please start a new thread if there is nothing in this forum that already represents your specific issue.

[k1k]

Dear jack01,

It seems that you have not read my post carefully. I just want to help you. I do really hope that the problems are with changed files only, because you will solve your issues very fast. However I have one simple idea. Please start tcpdump for your outgoing traffic from port 80. I hope you wont see so many "<iframe>" java injections as I did. However if you can see many java-s then you have the same problem....

[jack01]

Actually it sounds to me as though perhaps you have not read through this entire thread properly... Files HAVE been changed and we have verified that FTP download/upload has occurred for affected sites. And no, it is not resolved very easily, as we have been discovering in this thread.

[rpmws]

Hi,
Yes, I use RVSkin, and when I questioned if this might be the case the RVSkin author came on here and pretty much denied there was any problem with RVSkin...



Since no-one else at that time said 'that sounds like the old rvskin problem' I concluded that RVSkin was not the issue... However, from what you're (rpmws) saying, there is in fact an RVSkin issue... Is there a fix for it - and do I need to get all my customers to change their passwords now?

Thanks for your help rpmws - it is very much appreciated!

Regards,
Steve

Listen RVSkin is a fine product and I love it. But when I read your post the first thing that came to mind was the RVSkin I read about back several months ago. It may have been as long as 8 months ago. I can't remember now. I do KNOW that RVSkin developer released a new version that fixed the potential problem and made that update available and I want to say I believe even posted to this forum for people to update. Your "hacker" may have nothing to do with RVSkin at all. It's just what came to mind when you described it.

[gundamz]

Do you know what i found i last weekend?

They attack us again. I manage to trace down to the FILES they USED!

My situation is, almost 90% of the accounts on the server get affected.

I am SHOCKED TO KNOW that they have our server root password.

Basically, they are doing ftp://username:ROOTPASSWORD@domain.com... to connect to every accounts on the server.

That explain WHY no matter how you change your ftp password, they still can login !

Along with that, they are connecting to external mysql db to retrieve the login details.

if you have mySQL port open TCP in/out, CLOSED IT!

And change your ROOT PASSWORD. set different pass for mysql root password.

till now, i am wondering how they got hold of the root pass.

[jack01]

gundamz,

Could you explain for us how you figured out that they use ftp://username:ROOTPASSWORD@domain.com ? Did you see that in domlogs or messages etc.?

Thanks.

[rpmws]

Do you know what i found i last weekend?

They attack us again. I manage to trace down to the FILES they USED!

My situation is, almost 90% of the accounts on the server get affected.

I am SHOCKED TO KNOW that they have our server root password.

Basically, they are doing ftp://username:ROOTPASSWORD@domain.com... to connect to every accounts on the server.

That explain WHY no matter how you change your ftp password, they still can login !

Along with that, they are connecting to external mysql db to retrieve the login details.

if you have mySQL port open TCP in/out, CLOSED IT!

And change your ROOT PASSWORD. set different pass for mysql root password.

till now, i am wondering how they got hold of the root pass.

if they have the root password ..then none of this matters. They can just login as root and it's their box at that point. why would they FTP ? how did they get root in the first place?

you know what we need? a honeypot