2

We have a Windows 2003 SP2 server system. Upon doing a security scan we have found out that we are getting:

SSH Protocol Version 1 Supported Vulnerability

Threat: The consequences of vulnerabilities present in SSH Version 1 include:

  • SSH protected traffic compromise
  • root shell access to the system running SSH server

What steps on the Windows side can we take to remediate this issue?

  • 2
    Windows Server 2003 doesn't have native SSH server support. You've got something third party installed which is running the service, and you'll need to identify what that is before you can resolve the problem. – Polynomial Oct 24 '16 at 15:11
  • 3
    The answer is to disable SSH-1. But since windows does not come with a SSH server by default you need to find out yourself which one you have and how to disable SSH-1. Also we cannot know if any users might be affected by this. – Steffen Ullrich Oct 24 '16 at 15:12
  • You need to pass from SSHv1 to SSHv2. – Vini7 Oct 24 '16 at 15:21
3

Why are you running SSH?

Having an SSH server running on Windows 2003 that you do not know about is highly suspect... it is not an included service.

Step one is to figure out why SSH is running, and if it even should be at all! A great place to start might be seeing what binary is opening the port with netstat -anb.

It might not be for providing a terminal. Some third party FTP servers offer SFTP which runs over SSH.

Hardening SSH

Provided that you are intentionally running some SSH server product, your goal would be to harden its configuration by disabling SSH v1 and insecure cipher suites (think MD5/SHA1, etc). Ultimately this is specific to what you are running, and would almost be a second question about that specific server software.

1

Steps that you should take:-

You should install fresh updated verion of openssh for windows

Vulnerabliy in SSHv1

In the SSH-1 authentication process, the server generates a 256-bit random number called a challenge. The challenge is then encrypted with the client's public key, so that only the client can decrypt it. The client receives the encrypted challenge and decrypts it. The client returns the challenge response: an MD5 hash of the concatentation of the challenge and the session ID. The server independently computes the expected challenge response by the same formula. If the client's challenge response matches what the server computed, then the server responds that client has successfully authenticated.

Unfortunately, a weakness has been discovered in the formula for computing a session ID from the server's public key. This discovery allows modification of a server's public host key without changing the derived session ID. Furthermore, the modified key is often much weaker than the original, so it is easily factored to create a corresponding private key. This new key pair can be used to negotiate multiple concurrent SSH connections with same the session ID.

The above weakness gives possibility of MIMT .

more over PROTOCOL DOWNGRADE attack is also possible if Server is allowing SSH v1 , In which an attacker can force client to connect to V1 , downgrading the session capabilities

V1 does give allows FORWARD SECRECY , opening off-line attack possibility

  • Step 1 should be to find out what SSH server is running on the system. Then either configure it to not use SSHv1 anymore or remove the software. It does not help to just add an additional SSH server because it does not fix the problems of the previous one. – Steffen Ullrich Oct 24 '16 at 17:19
  • @gsb005 This only applies if you have OpenSSH server installed, which may not be the case. – trognanders Oct 25 '16 at 5:46
  • Ssh vulnerabilities that I mentioned are generic , as vulnerabilities are due to library and cipher the opt for encryption – 8zero2.ops Oct 25 '16 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.