SecureBridge ComponentsAttack types and countermeasures
This article includes the general description of possible attack types on data transferred through insecure are, and recommendations for increasing data protection level.
This kind of attack allows attacker to decrypt data transferred through network and read it. The encrypted data can be intercepted and saved locally for future decryption.
SSH protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. It it necessary to ensure that all of the random numbers are of good quality, so the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs).
SecureBridge uses a pseudo random number generator having high cryptographic security and high enough entropy. Also there is a possibility for user to assign the initial random sequence that will be used for generating random numbers. This sequence can be formed by using processor steps counter, system timer information, or information of random mouse movements or pressure of keyboard keys.
Recommendation: To ensure high protection level, you should use a reliable initial sequence for random number generator. The sequence can be based, for example, on information about random mouse movements.
SecureBridge uses different encryption algorithms, such as AES, 3DES, Blowfish, and Cast128. They have no vulnerabilities found till now. SecureBridge supports session key changing provided by SSH protocol. As a rule changing the session key after transferring of certain data amount is enough to prevent an attacker from cracking the key. CBC and CTR encryption modes (contain previous block encrypting output) of some ciphers is theoretically vulnerable to cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is deemed difficult and not considered fully practicable, especially if relatively long block sizes are used. In addition, CBC mode vulnerability can be reduced with insertion of packets, containing random data.
Recommendation: Use the RekeyLimit property (Client.Options, Server.Options) for determining what data size should be transferred before session key is regenerated.
This kind of attacks consists in the following: attacker gets access to the data packet transferred through insecure network area, changes it and, and transmits further. To determine whether the data was changed when transferring through the insecure area, data integrity checking methods are used. SecureBridge, within the bounds of the SSH protocol, inserts the MAC field into every sending packet. This field is calculated on basis of session key, packet sequence number and packet contents. SHA1 or SHA2 hashing algorithms, which are secure enough, is basically used for MAC field calculation. Because MACs use a 32-bit sequence number, they might start to leak information after 2**32 packets have been sent. Changing the session key after transfer of certain data amount increases degree of data protection.
There are some cases of man-in-the-middle attacks to consider.
If the attacker tries to connect between the client and the server before the client initiates the connection. When the client initiates session, attacker, that mimics SSH server, offers its server public key. If the client already has the server public key, it can verify the key sent by attacker, and warn the user about this spurious server public key. If the user does not accept this unverified key, attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session-specific data from the server, since he does not have the private key of that server.
If the server public key was not securely delivered to the client and then verified, the client risk to accept the key substituted by the attacker, and the client cannot be sure that it is connected to the authentic server. This lets attacker to intercept and change the data transferred between the server and the client.
Server administrators must make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms may include certification by a trusted certification authority (CA), secured Web pages, physical pieces of paper, etc.
In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is not recommended.
Recommendation: It is necessary to care of safe server public keys transferring (see the Keys transferring topic).
One of few weaknesses of the SSH protocol is vulnerability to Denial of Service attacks. Attacker can heap server with authentication requests that takes all server computational resources, and the server becomes unable to handle inquiries. One of the ways to resolve this problem is to allow connecting only from a subset of clients known to have valid users.
Recommendation: Setup the MaxStartups server option of TScSSHServer, that specifies the maximum number of concurrent unauthenticated connections.
The password authentication mechanism assumes that the server has not been compromised. So, a violator can mimic an SSH server for the client that initiates the authentication procedure and recognize the password, that is fraught with serious consequences.
This vulnerability can be mitigated by using an alternative form of authentication, like public key authentication.
Public key authentication assumes that client public key passed to the server is not compromised. To ensure that the client public key accepted by the server is not substituted, it is recommended to use pass phrases on private keys, smart cards, or other technology.
Recommendation: Keep the private client key in an encrypted form specifying the Password and Algorithm properties of a Storage object. The public key should be transferred to the server with maximum caution to prevent key substitution. (see the Keys transferring topic).