The vast majority of affected systems are initially accessed using SSH with no indications of brute force or exploitation of the underlying service. Despite non-trivial passwords, intermediary users and nonstandard ports, the attacker is able to gain access to the affected servers with no password failures.
What it looks like is that information only known at the provider's level is used to gain access to the system. Or there is a major vulnerability in the SSH server which is not discovered yet.
Although I appreciate jdMorgan's efforts to minimize the current effects by reconfiguring Apache to not allow JS files, or at least restrict their use to a whitelist of trusted filenames, this will only be a temporary solution. According to the cpanel article the attackers seem to have easy root access to the infected systems and have infected a number of system files which may contain additional backdoors for them to install enhanced versions of the software.
To prevent this kind of attack you should take other measures IMHO.
Stop using control panel software and learn administring your server on the command line.
Uninstall your control panel software, because you not using it is not preventing hackers from using it.
Disable password and interactive access to your SSH server and switch to keys if possible. (This is no option for people who access their servers also from untrusted systems where they don't want to have their key files installed like me)
Disable access to your SSH server from all IPs except from a handful of IPs that you might use to attach to it.
Disable access to your SSH server from all IPs of your hosting provider, including IPs from the support helpdesk. My experience is that many SSH attacks come from nearby servers, probably because they are bypassing intrusion detection systems which most hosting providers have only placed on their main internet pipes. Disabling SSH access to the helpdesk of your hosting provider may sound strange, but my experience is that they will always still have access via a serial console, direct console or in emergency situations can reboot the server in single user mode or from an install disk.
Disable root access via SSH. Instead, use an intermediate user with low access rights that has to use su to become root.
Give the intermediate and root users different and difficult to guess passwords.
Let all needed processes with possible open TCP or UDP ports (httpd, mysqld, ntp, bind, sendmail, etc) run under low user-rights usernames (different usernames for different processes), don't assign passwords to these usernames and disallow them in your /etc/ssh/sshd_config file.
Upload your webserver scripts (HTML, PHP, JavaSript etc) under a different username than the Apache server is running on. Give the Apache user only read access to those files and their directories to prevent script modifications cia URL injections. Many open source packages have very bad behavious in this matter, as they need the Apache server to have write access to config files. In that case give temporary write access to those files while installing or updating your configuration, and make them readonly afterwards.
Use shadow passwd files (the default now on most distros) so no encrypted password viewing can be done by users without root rights. For example a simple PHP script can--even when running as a non privilidged user--with a simple include statement show the contents of your /etc/passwd file to a hacker.
Switch from the orignial DES encryption to MD5 encryption for your passwords. (default now on most systems). DES is easier to decrypt and MD5 allows passwords longer than 8 characters.
Change Linux user passwords only via the passwd command in a SSH shell, not via any control panel software as it may be fished.
Uninstall the wget package from your system as wget is one of the main commands to load infections on your machine. There are alternatives like sftp or rsync over SSH that you can use for data transfer between servers.
Only tell your intermediate user and root passwords to the hosting helpdesk on the moment you ask them to do work on your server.
Change passwords for the intermediate user and root as soon as the helpdesk has finished their job. Again, remember that in emergency situations they can always access your server via the console in single user mode or with an installation CD. No need to have your passwords on file with them.
If your hosting provider gives you a freshly installed server, stop and uninstall all services that you don't need. You will be surprised how many webservers are provided with bluetooth, PCMCIA, NFS, Samba, NIS, mouse drivers, X font servers and other tools enabled by default, which are handy in a desktop or corporate office environment but may be a security risk or potentially cause instability in an internet server configuration. Remember, on Redhat and Fedora systems, yum remove is your friend. Other distro's have similar commands to remove packages permanently from your server.
Update your system regularly with the newest tools/versions.
Check regularly with the command netstat -nlp as user root which processes are listening to TCP and UDP ports. Write a list down after first installation. Every change you see may be a backdoor installed by a rootkit.