Technical Notes

This technical note describes three security vulnerabilities in Reflection for Secure IT Windows Server (formerly known as F-Secure SSH Server for Windows). Please evaluate your exposure and either patch your systems with the fix we provide or apply the recommended workaround.

This note is presented in the following sections:

Attachmate apologizes for any inconvenience the discovery of these security vulnerabilities may cause you. Our aim is to provide products that keep your systems secure and available, and we take seriously the engineering of products to meet that goal. We have provided remedies as quickly as possible and made recommendations about applying those remedies. We urge you to look at your implementations of SSH on Windows servers to decide what course of action to take.

Important Reminder: Security update information affecting Reflection for Secure IT can be found on our web site in Technical Note 1910. We encourage you to bookmark this technical note and check it regularly for updates.

For information about other Reflection security updates, see Technical Note 1700.

Issue 1

Affected products:

This security vulnerability involves the permissions set on the host private key file.

When the SSH Windows server generates a host key pair, the permissions set for the key pair are insufficient to protect the host private key file. Any user who has successfully authenticated to the server and who has access to the server file system can read or copy the Windows server’s host key. A malicious user could launch a host impersonation attack by copying the host key to a different server and then pretending to be the original server.

We are not aware of any exploits of this vulnerability, but we recommend that you fix it immediately.

Fix/Workaround

The problem is fixed in Reflection for Secure IT Windows Server 6.0 Build 24. In this version, the private key permissions have been modified so that only the Administrator group has access to the file. The permissions of existing private keys are updated when Build 24 is installed and the server is restarted. New private keys generated after the update are created with the more secure permissions.

If you have an existing installation, but cannot update or do not want to update to Reflection for Secure IT Windows Server 6.0 Build 24, you can manually modify the host private key file so that it is readable by the Administrator group only. The default location of the file is:

Note: You may have modified the default location of this file when you installed the server.

Whether you update the SSH server to Reflection for Secure IT 6.0 Build 24 or manually change the permissions on the host key file, we recommend generating new host keys for all Windows servers to ensure that this vulnerability cannot be exploited.

Note: When server host keys are regenerated, users receive a warning message stating that the host's key has changed. Let your users know to expect this behavior, or generate and distribute new known_hosts files that include the new keys.

Updating the SSH Windows Server

Maintained customers are eligible to receive the update package for the Windows SSH server (Reflection for Secure IT Windows Server 6.0 Build 24) from the Download Library.

If you are currently logged in to the Product Upgrades site, skip to step 3.

1. Log in to https://download.attachmate.com/Login.aspx?ReturnUrl=%2fupgrades%2fDownloadAgreement.aspx%3fcode%3dRSS-WN&code=RSS-WN using the Product Upgrades user name and password that you received from Attachmate.

2. After you log in, click File Download, and accept the Software License Agreement.
3. Click the file name to download the 6.0 Build 24 product.

Issue 2

Affected product:

This security vulnerability involves user keys for built-in accounts that have been renamed.

Microsoft Windows Server 2003 and Microsoft Windows 2000 Server ship with built-in accounts, such as Administrator and Guest. Microsoft recommends that these accounts be renamed or disabled in order to prevent potential hackers from exploiting them.

If either of these accounts was renamed after being configured for SSH public key authentication, there is potential for a security breach as the server will continue to accept user keys from users who authenticated via public key to the original Guest or Administrator account.

This is a problem only if SSH was configured to run on the server with public key authentication and with built-in accounts that were subsequently renamed. We are not aware of any exploits of this vulnerability, but we do recommend that you fix it immediately.

Workarounds

There are two possible workarounds. Please select the one that works better in your environment.

Workaround 1

Change the server configuration using the GUI as follows:

1. Add the string administrator to the Deny login for users in User Restrictions.
2. Create a subconfiguration entry in the Advanced screen by adding a UserSpecificConfig line to the end of the file, for example:

3. Click Apply to notify the running server of the changes.
4. Create a file named admin.config in the folder where the server was installed (usually "C:\Program Files\F-Secure\ssh server"); the file should contain the following line:

Note: The doubled \\ is required. The permissions of the sshd2_config and admin.config files should be changed to permit only the Administrator group access to these files.

Workaround 2

Follow these steps to move and restrict access to the security files:

1. In the Documents and Settings folder, create a new folder using the new Administrator user name as the folder name. For example, "C:\Documents and Settings\New-Admin-Name."
2. In the new folder, create a new .ssh2 folder. For example, "C:\Documents and Settings\New-Admin-Name\.ssh2."
3. Move all public key files and the authorization file to the new \.ssh2 folder.

4. Set the .ssh2 folder permissions to allow only the New-Admin-Name user access to these files.

Issue 3

Affected product:

This vulnerability involves using regular expressions in denying and allowing users access to the system.

In the 6.0 version of the server, regular expressions are evaluated in a case sensitive manner, where prior versions were case insensitive. Therefore, in version 6.0 if you have a user name string defined for joeuser, the server accepts connections from all case combinations of this name, such as Joeuser and JoEuSer.

We are not aware of any exploits of this vulnerability, but we recommend that you fix it immediately.

Fix/Workaround

The problem is fixed in Reflection for Secure IT Windows Server 6.0 Build 24. In this version, the string evaluation is case insensitive, as it was in versions prior to 6.0. To obtain the updated Reflection package, follow the steps given in the Updating the SSH Windows Server section above. If upgrading is not an option, a possible workaround is to enter all possible case combinations of each user name string.

Contacting Technical Support

If you have questions about this security information, please contact technical support. For contact information, see http://support.attachmate.com/contact/.