Subject: SECURITY ALERT: Horde arbitrary file inclusion vulnerability

An arbitrary file inclusion vulnerability has been discovered in the Horde webmail application. At present, we can confirm that this security vulnerability in question affects Horde 3.1.6 and earlier. Based on incomplete information at this time, we also believe this affects Horde Groupware 1.0.4 and earlier as well (cPanel does not use Horde Groupware at this time).

cPanel customers should update their cPanel and WHM servers immediately to prevent any chance of compromise. The patch will be available in builds 11.18.2 and greater (or 11.19.2 and greater for EDGE systems). The updated builds will be available immediately to all fast update servers. The builds will be available to all other update servers within one hour of this posting.

To check which version of cPanel and WHM is on your server, simply log into WebHost Manager (WHM) and look in the top right corner, or execute the following command from the command line as root:

/usr/local/cpanel/cpanel -V

You can upgrade your server by navigating to ‘cPanel’ -> ‘Upgrade to Latest Version’ in WebHost Manager or by executing the following from the command line as root:

/scripts/upcp

It is recommended that all use of Horde 3.1.6 and earlier be stopped (on cPanel and non-cPanel systems alike) until Horde updates can be applied. You can disable Horde on your cPanel system by unchecking the box next to ‘Server Configuration’ -> ‘Tweak Settings’ -> ‘Mail’ -> ‘Horde Webmail’ within WHM, and saving the page with the new settings.

We would like to thank HostGator for providing the initial details in their report of this vulnerability.

cPanel announced today that it’s security team has identified several key components of a hack known as the Random JavaScript Toolkit. The systems affected by this hack appear to be Linux® based and are running a number of different hosting platforms. While this compromise is not believed to be specific to systems running cPanel® software, cPanel has worked with a number of hosting providers and server owners to investigate this compromise.

The cPanel Security Team has recognized that 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. The cPanel security team also recognized that a majority of the affected servers come from a single undisclosed data-center. All affected systems have passwordbased authentication enabled. Based upon these findings, the cPanel security team believes that the attacker has gained access to a database of root login credentials for a large group of Linux servers. Once an attacker manually gains access to a system they can then perform various tasks. The hacker can download, compile, and execute a log cleaning script in order to hide their tracks. They also can download a customized root-kit based off of Boxer version 0.99 beta 3. Finally, the attacker searches for files containing credit card related phrases such as cvc, cvv, and authorize.

The actual root-kit has been the subject of much speculation. The cPanel security team asserts that the Boxer variant includes a small web-server which is how the Javascript is distributed to unsuspecting users of any website on the server. It is believed that the Javascript include is injected into the HTML code after Apache® has served the file but before it has traveled through the TCP transport back to the user of the website. The web-server is not loaded onto the hard drive directly but loaded directly into memory from the infected Boxer binaries. More information about the infected binaries can be found at: http://www.cpanel.net/security/notes/random_js_toolkit.html.
The JavaScript being loaded by this web-server is directing users to another server that scans the website user for a number of known vulnerabilities. These vulnerabilities are then used to add the website user to a bot net. More information about the JavaScript hacks can be found at:
http://www.finjan.com/Pressrelease.aspx?id=1820&PressLan=1819&lan=3.
Cleaning the Random JavaScript Toolkit requires the server to be booted into single user mode and the removal of all infected binaries. More details on how to do this can be found at: http://www.cpanel.net/security/notes/random_js_toolkit.html. The cPanel security team believes that the hacker has access to the database of login credentials, the only way to prevent being hacked again is changing the password and not releasing it to
anyone. The preferred method however is to move to SSH Keys and remove password authentication altogether.

This compromise has been in the media lately and discussions can be found at the following locations:
http://www.pcworld.com/article/id,141358-c,techindustrytrends/article.html
http://it.slashdot.org/it/08/01/25/148244.shtml

Please note that these tips are suggestions only and cPanel takes no responsibility for modifications to individual servers, or the security practices of individual servers. Server security is a collection of compromises, as any server that allows connections could be insecure. These tips are to be followed at your own risk.

1) Use secure passwords!

Insecure passwords are the most common security vulnerability for most servers. If an account password is insecure and is compromised, client sites can be defaced, infected, or used to spread viruses. Having secure passwords is paramount to having a secure server.

You can edit /etc/login.defs to configure many password options on your system. It is well documented.

Generally, a password utilizing at least 8 characters including alphanumeric and grammatical symbols is sufficient. Never use passwords based upon dictionary words or significant dates. If you are uncertain about the security of a password, then you can test it using JTR cracker. If a password can be broken in a few hours, then it is probably too insecure and should not be used. You can also install tools like pam_passwdqc to check the strength of passwords.

2) Secure SSH

Enable public key authentication for SSH and disable password authentication read more >>

Move SSH access to a different port. People are looking for port 22 as a possible way to access your servers. Moving SSH to a different port will add a simple way to deter those without specific knowledge of your server from easily discovering your SSH port.

You can modify the port that SSH runs on within /etc/ssh/sshd_config. Change the line that says #Port 22 to a different port such as: Port 1653. Make sure to keep your current SSH session open when testing the new port so you can change back to port 22 if the new port doesn’t work.

You should always use SSHv2 only as SSHv1 is not secure. Make sure to change the line in /etc/ssh/sshd_config that says #Protocol 2,1 to Protocol 2.

You may also wish to set Shell Resource Limits for you users to prevent applications and scripts from using all up your resources and taking down your server. You can configure shell resource limits in /etc/security/limits.conf on most Linux systems.

3) Secure Apache

The most readily available way to access a web server, is of course, the web server application. It is important to take steps to secure your Apache installation.

One of the best tools for preventing malicious Apache use is mod_security. This can be installed in Addon Modules in the cPanel section of WebHost Manager. You can find information about mod_security at http://www.modsecurity.org/.

When compiling Apache, you should include suexec to ensure that CGI applications and scripts run as the user that owns / executes them. This will help identify where malicious scripts are and who is running them. It will also enforce permission and environment controls.

We also recommend compiling Apache + PHP with PHPsuexec. PHPsuexec forces all PHP scripts to run as the user who owns the script. This means that you will be able to identify the owner of all PHP scripts running on your server. If one is malicious, you will be able to find it’s owner quickly and resolve the issue. To compile Apache + PHP with PHPsuexec, select the PHPSuexec option in the Apache Upgrade interface in WHM or when running /scripts/easyapache from the command line.

You should enable PHP’s open_basedir protection. This protection will prevent users from open files outside of their home directory with PHP. This can be enabled in Tweak Security within WebHost Manager.

You may also wish to include safe_mode for PHP 5.x and below. Safe_mode ensures that the owner of a PHP script matches the owner of any files to be operated on. You can enable safe_mode by changing the safe_mode = line in php.ini to safe_mode = On.

4) Secure your /tmp partition

We recommend that you use a separate partition for /tmp that is mounted with nosetuid. Nosetuid will force a process to run with the privileges of it’s executor. You may also wish to mount /tmp with noexec after installing cPanel. Check the mount man page for more information.

Also, Running /scripts/securetmp will mount your /tmp partition to a temporary file for extra security.

5) Upgrade your mail to maildir format

Maildir format adds extra security and speed to your mail system. Newer installs use maildir by default. If you’re running an older copy of cPanel, you’ll probably want to upgrade using /scripts/convert2maildir. Make sure to back up your current mail before converting to maildir, this can be done within /scripts/convert2maildir. If you see maildir is enabled when running /scripts/convert2maildir, you are already using maildir, and will not need to convert.

6) Lock down your system’s compilers

Most users do not require the use of C and C++ compilers. You can use the Compilers Tweak within Tweak Security in WebHost Manager to turn off use of the compilers for all unprivileged users, or to disable them for specific users only. Many pre-packaged exploits require working compilers. Disabling compilers will help protect against many exploits.

7) Turn off unused services and daemons

Any service or daemon that allows a connection to be established to your server is away for hackers to gain access. To reduce security risks, you should disable all services and daemons that are not being used.

For Daemons on Linux:

Check /etc/xinetd.conf for services you are not using. For example, cupsd (printing daemon) and nfs/statd (network file system daemons) are not used on many systems.

For Services:

Go to the Service Manager in the Service Configuration section of WHM and disable any services that you are not using.

Monitor your system

It is important to be up to date on what is going on with your system. Make sure that you know when accounts are being created, what software is being installed, when software needs updates, etc.

Check your system frequently to ensure it is functioning in the way you expect. Make sure to check things like:

netstat -anp : Look for programs attached to ports that you did not install / authorize

find / \( -perm -a+w \) ! -type l >> world_writable.txt : Look at world_writable.txt to see all world writable files and directories. This will reveal locations where an attacker can store files on your system. NOTE: Fixing permissions on some PHP/CGI scripts that are not properly coded will break them.

find / -nouser -o -nogroup >> no_owner.txt : Look at no_owner for all files that do not have a user or group associated with them. All files should be owned by a specific user or group to restrict access to them.

ls /var/log/: There are many different logs on your system which can be valuable resources. Check your system logs, apache logs, mail logs, and other logs frequently to make sure your system is functioning as expected.

There are many readily available utilities to monitor your system and to detect rootkits, backdoors, etc. Here are some commonly available utilities:

• Tripwire - Monitors checksums of files and reports changes.
  http://tripwire.com or http://sourceforge.net/projects/tripwire
• Chrookit - Scans for common rootkits, backdoors, etc.
  http://www.chkrootkit.org
• Rkhunter - Scans for common rootkits, backdoors, etc.
  http://www.rootkit.nl/projects/rootkit_hunter.html
• Logwatch - Monitors and reports on daily system activity.
  http://logwatch.org

9) Enable a Firewall

Installing a firewall to limit access to your server is useful. Removing all unused software on your system is more useful. Before you have the chance to remove all unused services and daemons, or the chance to figure out which services / daemons are unused, you can enable a firewall to prevent unwanted access.

The following will show the ports cPanel and WHM need open to function properly and what the port is used for:

http://faq.cpanel.net/show.cgi?qa=104689180407630

If you are using APF, see:

http://faq.cpanel.net/show.cgi?qa=108499296901804

Please note that these ports are for all services that can be used by cPanel and WHM, you may or may not be using all of these services or other services and should adjust your rules accordingly.

Remember to set a cron job to disable your firewall every 5 minutes when testing your rules, or you may be locked out of your server.

10) Stay up to date

It is important to make sure that you are running the latest stable versions of the software on your system to ensure that it has been patched of any security issues that past versions may be susceptible to. Make sure to keep on top of updates for:

• Kernel
• cPanel and WHM*
• User Applications (bulletin boards, CMS, blog engines, etc)**
• System Software*

*These can be set to automatically update in WebHost Manager under Update Config in the Server Configuration section.

**You can upgrade all cPAddon installations through Manage cPAddons in the cPanel section of WebHost Manager.

Overview

There are many different firewalls that are installed by default on Linux systems (ipfw, apf, iptables). This article is designed to help you get the most out of your system firewall software when using cPanel and WHM.

cPanel and WHM install and manage a number of different services on your system. Many of these services require an outside connection to function properly. Therefore, holes in the firewall will need to be opened for the ports that these services are running on. Rather than providing a default set of ports for you to open, this article will provide a list of ports used by cPanel and WHM and the respective services they manage in order for you to be able to set up rules for your server. You should only open ports that you will definitely be using.

Ports

Of the above ports, it is only recommended to use the SSL version of each service if possible (except for HTTP and HTTPS which both can be used). Using a non-SSL version of those services means that information (such as logins and passwords) is submitted in plain text across the net for attackers to potentially intercept. You can use the Manage Service Certificates feature in WHM (WHM >> SSL/TLS >> Manage Service Certificates) to ensure that your services have SSL certificates installed.

Example Configurations

The following examples are used to show how to add rules with APF, iptables, and ipfw. These examples will not provide a complete solution to your firewall rules as you should always use the set of rules that matches your services, not a default set of rules that you copy and paste.

IPFW

To enable IPFW on FreeBSD, you’ll need to ensure that the line firewall_enable=”YES” is present in /etc/rc.conf. The firewall_script variable should be set to the path of your firewall rules. You can check your rules at any time by running ipfw list.

Here’s a sample rule file allowing HTTP and HTTPS access to your system. Please note that it assumes you are using eth0 as your public interface.

For more information on IPFW, see the manual

APF

APF is basically a frontend for iptables that allows you to open or close ports easily without understanding iptables syntax. Here’s a sample of 2 rules to add to /etc/apf/conf.apf to allow HTTP and HTTPS access to your system:

For more information on APF, see the APF site.

iptables

While APF is simple to use, iptables offers more customization of your packet filtering rules. Iptables requires some knoeledge of the TCP/IP stack. Here’s an example of iptables rules for HTTP traffic on port 80. Please note that it assumes you have a DMZ set up on eth0 for 192.168.1.1 and a broadcast IP of 66.66.66.66

For more information on iptables, see the iptables site or by typing man iptables from the command line.

What now?

From here, you’ll need to determine what firewall software to use and make sure you are familiar with its usage. Always remember to leave yourself a way back in when working with firewall rules so you don’t get locked out of your own server. A cron job that disables the firewall every 5 minutes is a simple way back in.

Other tools

• Mod_Security - While not specifically a firewall, mod_security allows you to accept or deny http traffic based on a set of rules. It is fantastic for stopping DoS attacks against Apache and for preventing poorly coded applications from allowing access to your system
• CSF - CSF is a security suite that enhances your security settings on cPanel and WHM servers in a number of ways. It is a great tool and includes firewall configuration

Overview

The best principle of security is to not offer something to be broken into. That’s also the theory behind Host Access Control. Here, you can tune access permissions to the services on your server.

New for cPanel 11, Host Access Control allows you to specify what IPs you’d like to give access to specific services. For example, if you only have 5 users on a machine with shell access, limit sshd to connections from their IPs and you’ll have almost no chance of a malicious user getting in through ssh. The same can be said for other services as well.

It is important to note that the “Security is the inverse of convenience” statement definitely holds true here. You’ll need to be careful about what rules you add so you don’t lock yourself or your users out. You’ll also need to add new IPs each time more access is needed. That’s a small price to pay for locking your server down tight. Probably a lot less time than bringing back up a hacked box.

Host Access Control can be found in the Security Center in WHM for versions 11.0 and higher.

Overview

We’ve all been faced with the problem of weak passwords. As much as you inform users about password security, they want to use something they can easily remember. So, we end up with passwords like ‘ilovejohn’ and ‘toyota90210′. Even with the new password strength meters in cPanel, it is important to go that extra step to make sure that your users are protected, well, from themselves.

cPanel 11 marks the release of cPHulk, a brute force password protection system. With cPHulk, you can set a threshold for authentication attempts on services like POP3, cPanel, WHM, FTP, etc. After a certain amount of attempts, the attacker will no longer be able to authenticate.

It’s a simple concept really, if the door is locked, they probably can’t get in. What makes cPHulk special is that you can configure lock out times, thresholds by account or ip, and whether or not to add to lock out times if further attempts are made after the account is locked. As well, the attacker can’t tell the account is locked so they’ll continue to try and authenticate and you’ll get some good log information about the attack.

cPHulk can be found in the Security Center in WHM for versions 11.0 and higher. There, you can also view recent brute force authentication attempts.

Overview

It is very important to control who has access to your server. A great tool for locking down access to your server is requiring the use of public key authentication for SSH access. Public key authentication uses a set of two keys, a private key, and a public key to authenticate users connecting to your server. The public key resides on your server, and a private key that corresponds with that public key resides on the user’s machine. The private key is a secret file that matches with the public key to allow a connection. Only those with the private key will be able to connect.

Private keys can be encrypted using 1024-4096 bit encryption in either RSA or DSA format. These keys are so secure that supercomputers could take years to break even the least encrypted 1024 bit keys.

Some things to note when enabling public key authentication:

More difficult for users: You will need to instruct them on creating public and private keys and protecting their private key. Once they have their private key created and configured in their SSH program, there is no extra work involved. This added level of difficulty for users is definitely worth the extra security that public key authentication provides.

Private keys are precious: You and your users must treat private keys as highly secret items. They should never be given out as they are a key to accessing your server and anyone with access to a private key can access your server. This is why we recommend password protecting private keys so that only those who both have the key, and know the password, can connect.

Getting Started

Ok, so now that we’ve convinced you that public key authentication is important to server security and that it is worth the extra bit of work, it’s time to get started. The first step to enabling public key authentication, it notifying your users. You’ll need to make them aware of the change, and aware of the steps they need to take to work with this new system. Don’t worry, this is a simple step, and we’ve prepared some information for you:

Public Key Authentication Guide for Users

Click here for the guide.

Setting up Your Keys

You’ll need to create keys for your WHM user as well. To do this, go to Manage SSH Keys in WebHost Manager. You can then generate a key under Generate a New Key and use it according the the instructions in the guide for users.

Enabling Public Key Authentication and Disabling Password Authentication

Once you’ve created your public and private key pair, have downloaded it to your local machine, and are able to connect with your key through ssh, it’s time to turn off password authentication. To do this, go to Tweak Security in the Security section of WebHost Manager and configure the SSH Password Auth Tweak. Make sure this is set to disabled by clicking on Disable Password Auth.

Try connecting via ssh and to make sure it looks for a private key. You should not be able to connect without a private key.

Now, sit back and relax as hackers will no longer be able to gain ssh access through password cracking.

What is Public Key Authentication?

Public key authentication uses a public and a private key when connecting to a server for added security. Public and private key are similar to a puzzle. They are created together to use during the login/authentication process. The public key resides on the server (the remote location) The private key resides locally on your computer/server. When you attempt to login to a server, the public and private key are compared. If they "match", then you will be allowed to login to the server location.

Why does Public Key Authentication benefit me?

Public Key Authentication keeps the server that your site(s) is(are) on more secure. No longer can your password to access the server be guessed or cracked by hackers. Now, to access the server, both your private key, and a password are needed. Even if someone knows your password, they will need to obtain your private key to gain access. Wthout the private key, they cannot access the server.

This also holds true with everyone else on the server. Now, all their accounts are more secure as well. This reduces the risk of server wide problems and will keep your account and the whole server more secure.

How do I use Public Key Authentication?

Using Public Key Authentication is simple. To use public key authentication, you’ll need to complete the following steps:

1) Create a Public / Private key pair: All public and private keys come in pairs and only the 2 keys in the pair can be used together. You’ll need to create a key pair to access the server. To do so, go to your cPanel interface, then to SSH/Shell Access, and then to Manage SSH Keys:

• Click on Generate a new Key.
• Give the key a name, for example: john_smith_private_key
• Add a password to secure your key.
• Select DSA.
• Select 4096.
• Click on Generate Key. (This may take a few minutes)

2) Authorize your keys

Once a key pair is created, you’ll need to authorize it for use. To do so:

• Navigate to the Manage SSH Keys section.
• Click on Manage Authorization next to the key you wish to use.
• Click on Authorize.

3) Download your private key

• Navigate to the Manage SSH Keys section.
• Click on View/Download next to the private key you wish to use.
• Click on Download Key.
• Save this key on your hard drive and do not give it out to anyone!

4) Configure your SSH Program

To do this, you’ll need to read the instructions in your ssh program of choice. If you are using PuTTy, you’ll need to use the conversion tool when downloading your private key to make sure it works with PuTTy. If you wish to connect without downloading a SSH program, you can do the following.

1. Navigate to the SSH/Shell Access section.
2. Click on Connect using SSHTerm (requires java). (You’ll need to make sure that Java is enabled on your web browser)
3. Click on ‘ok’ if you are asked to trust a SSL certificate. Enter the username and password you use to access your cPanel account.
4. Click on File -> New Connection
5. Enter the name of your site as the Host to Connect to
6. Click on Advanced
7. Enter the port your webhost gave you to connect to SSH as the Port
8. Enter your cPanel account username as the Username
9. Click on publickey as the Authentication Method
10. Click on Connect
11. Select your private key file when the window comes up to select a file and click on Open.
12. Enter the key password when prompted.
13. Click ‘OK’ if you get a message about X11 forwarding
14. You should now be connected to the shell.

Back to the Public Key Authentication Gude

http://secunia.com/advisories/23587/

———————————————
Summary:
———————————————

Due to a recently discovered bug, it will be necessary for users
who are running the CURRENT, RELEASE and STABLE branches to run a cPanel software update.

———————————————
Description:
———————————————
An uncompilied mysqladmin script allowed an exploited copy of MySQL.pm to be places within the directory location of mysqladmin. This copy of MySQL.pm would be given preference by mysqladmin due to the precedence order of perl module searches. A malicious user could then use an exploited copy of MySQL.pm to elevate their system access (including root access).

A patch for this issue has been released. Please note that this is a local issue and a system cannot be compromised remotely. The malicious user must have access to an account on the system to take advantage of this script.

All cPanel and WHM server will automatically receive a patch for this update. This patch has been applied to most servers and will be applied to the remaining number of servers during the scheduled update on Sunday night, September 25th, 2006. It can be applied manually as per the instructions below.

———————————————
References:
———————————————

None

———————————————
Affected Systems:
———————————————

All builds on all platforms are vulnerable up to and including (11.0.0
build 492), all builds after that have been fixed. All previous builds after 9.0.0
will be automatically patched by the updater if automatic updates are set.

———————————————
Fix Details:
———————————————
We recommend updating (if you do not wish to update see the manual patch instructions below) to the latest EDGE or CURRENT build as these builds include the latest security patch as well as additional protection (the underlying wrapper now contains vastly improved input sanitization). To do this, you will need to modify your upgrade settings thorugh the ?Update Config? function in the ?Server Configuration? menu of WebHost Manager.

Login to WebHost Manager
Naviagte to the the ?Update Config? function in the ?Server Configuration? menu.
Change your cPanel/WHM Updates option to CURRENT or bleeding EDGE (Automatic updates recommended).
Click on ?Save?
Use the ?Upgrade to Latest Version? option within the ?cPanel? menu.

You can also apply the patch without updating:

You can either run /scripts/upcp from the command line as root, or you can also upgrade from inside WebHostManager by using the ?Upgrade to Latest Version? option within the ?cPanel? menu.

You may also apply just the patch manually through the following steps:

SSH into your server and gain root access
wget -q -O - http://layer1.cpanel.net/installer/sec092506.pl | perl

You can verified the server is patched by running:

wget -q -O - http://layer1.cpanel.net/installer/cpanel_exploit_checker_092406.pl | perl

———————————————

If you find there is still a problem after updating to the version(s) mentioned above, please file a support ticket with the cPanel Technical Support team at https://tickets.cpanel.net/submit/index.cgi?reqtype=tickets

———————————————
Credits
———————————————
Information in this advisory was obtained from information provided from:
Brent Oxley (Host Gator)
Rob Brown (Blue Host)