How realistic and possible is this sort of attack

Question

I scanned a host with Nessus, in order to do a vulnerability Assessment, and one of the findings looked really odd to me.

Nessus rated this finding's risk as Medium. The finding was, that a service uses an SSL certificate which supports the use of Medium strength SSL ciphers with known weaknesses, and hence can impose a threat. Now, let us assume that this SSL certificate is not from a known CA, but came with a security product, for this case we can say Juniper SA (SSL VPN), and is presented on the login page. What are the threats here, are they really possible, do they really justify a Medium risk level, if it only "supports" the use-of, and I use strong SSL ciphers, does that justify a Medium risk (I guess it can't know that), and what does it say about a security vendor that issues a "weak" certificate with a product of his?

I personally have a feeling (just a feeling, no technical knowledge on this sort of possible-attack) that this attack is very difficult to launch and to have success with.

Any thoughts?

Answer 1

Allowing SSLv2 with weak ciphers exposes you to several potential attacks and is not worth the risk. If you only plan on using strong ciphers, is easy enough to restrict the SA VPN to only allowing SSLv3 and TLS1 with 168bit ciphers on the Configuration>Security tab. You will even note that there is a warning on that page indicating known vulnerabilities with SSLv2.

One example MITM attack against SSLv2, during session negotiation an attacker can remove the strong ciphers from the available list in the conversation and force the server to negotiate with a weak one. The rest of the traffic can be collected using a packet sniffer and decrypted later. The user would have no indication that this happened and 40 bit encryption can be decrypted in less than a day on today's hardware.

Unrelated to your question but since you mentioned it... you should also replace that factory supplied SSL certificate with one signed by a trusted CA. Nessus should have also flagged that as an issue.

Answer 2

The Risk score doesn't mean much without context. What risk does this vulnerability increase? Unfortunately, it's complicated enough to always require some amount of human judgement.

One standard way of providing context is by using CVSS (Common Vulnerability Scoring System) Vectors: http://nvd.nist.gov/cvss.cfm?vectorinfo&version=2

CVSS vectors containing only base metrics take the following form:
(AV:[L,A,N]/AC:[H,M,L]/Au:[N,S,M]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C])

The letters within brackets represent possible values of a CVSS metric. Exactly one
option must be chosen for each set of brackets. Letters not within brackets are 
mandatory and must be included in order to create a valid CVSS vector. Each letter or 
pair of letters is an abbreviation for a metric or metric value within CVSS. These 
abbreviations are defined below.

Example 1: (AV:L/AC:H/Au:N/C:N/I:P/A:C)
Example 2: (AV:A/AC:L/Au:M/C:C/I:N/A:P)

Metric: AV = Access Vector (Related exploit range)
Possible Values: L = Local access, A = Adjacent network, N = Network

Metric: AC = Access Complexity (Required attack complexity)
Possible Values: H = High, M = Medium, L = Low

Metric: Au = Authentication (Level of authentication needed to exploit)
Possible Values: N= None required, S= Requires single instance, M= Requires 
multiple instances

Metric: C = Conf Impact (Confidentiality impact)
Possible Values: N = None, P = Partial, C = Complete

Metric: I = Integ Impact (Integrity impact)
Possible Values: N = None, P = Partial, C = Complete

Metric: A = Avail Impact (Availability impact)
Possible Values: N = None, P = Partial, C = Complete