Quote:

---

We were also hit by this

We are also hosted by layered technologies.

What we can tell you from our experience from this:

We have multiple servers hosted by LT

Only 2 of our servers with LT were affected by this.

Server 1 - All accounts affected (register_globals enabled)
Server 2 - Only around 5 accounts affected (register_globals enabled)

NOTE: On both of these servers that were affected we have logged that new clients have signed up very recently and requested that php function: fopen be enabled on the server for a "Ebay listing" script to work. So we went ahead and enabled it

All other servers: fopen never requested to be enabled

Now on server1 we realized that all accounts were affected once we received emails from our customers. We then immediately turned of register_globals on all servers as we realized what was going on.

Now as you can see on "server 2" only around 5 accounts were affected. We believe this is because we turned off register_globals just in time.

This is what has happened on the servers that were affected:
1. All accounts in the /home directory were chowned to a different user. Now as we are running suphp this screws up all php applications as they have to be run under the actual account owner. (big headache)

2. many files in ALL user directories with extensions such as .php and .html were injected with the code many of you are talking about
(ALSO NOTE: that even files completely written in php code and even some zend/ioncube encrypted files had the code injected to them seamlessly. We have even seen the code injected into complex php code, not just at the last line of every file.

Then after a while the entire php/apache structure on "server 1" complete became corrupt.

Basically all php sites came up with 500 errors. We checked the error log and it displayed absolutely no error logs and reasons why.

So we went ahead and tried to recompile the entire apache system and php configuration.

What happened? After every recompile it would compile entirely back to the version that we were running before that was corrupt.

After checking the configuration files it showed that somehow it was edited to make it always go back to the version that was corrupted.

Once we got this fixed we recompiled and everything was back to normal. But then we still had the 500 errors. This is because of all of the files by the users had been chowned to a different user.

Now if you host many users on a server thats going to be a headache to chown every single file. So here is a script that you can use to have all ownerships set back to normal.

1. log in to ssh
2. touch perm
3. chmod 777 perm
4. pico perm
5. Insert this code

#!/bin/bash
cd /var/cpanel/users
for user in *
do
chown -R $user.$user /home/$user/public_html/*
done

6. Then save file
7. execute the file: ./perm

That should fix all permissions of your users.

We then also went ahead and re-hardened our php.
We are currently running with register_globals disabled and fopen disabled.
Heres a list of other php functions that we recommend disabling also:

exec, shell_exec, system, passthru, shell_exec, popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate

You are then going to want to install mod_security as this will really help against web based attacks if it is configured well.

Everything is now back to normal on the affected servers

Hope this helps other web hosts out there. Wish we could submit more information but as you can see we are bogged down with security issues.

---

Quote:

---

I have about six AV programs working simultaneously though, so the virus has to go through a Phalanx to get to me.

---

Quote:

---

who would want to hack hC?

---