1

Our vulnerability scanner (Saint-based) is claiming that a large number of devices and servers are susceptible to the SSL/TLS renegotiation flaw (CVE-2009-3555). Most of these servers and devices are fairly up-to-date on patches / firmware.

Since the issue is 5+ years old, I suspect that the issues reported are mainly false positives.

To verify, I ran this:

openssl s_client -connect x.x.x.x:443
<snip>
GET / HTTP/1.1
R
RENEGOTIATING
depth=0 CN = X.X.X.X, L = Utopia, ST = UU, C = US, O = Acme, OU = IT
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = X.X.X.X, L = Utopia, ST = UU, C = US, O = Acme, OU = IT
verify return:1

read:errno=0
(CRLF)

So the server is saying, "RENEGOTIATING", which seems to indicate that it is vulnerable but it does not deliver content upon the subsequent CRLF, which seems to indicate that it is not vulnerable.

Based on the above, is this device vulnerable? Is there a better way to test? I just need a reliable way to confirm before writing off as false positive or trying to find a fix.

Jim Balo
  • 270
  • 2
  • 4
  • 13

1 Answers1

0

Jim, based on your results, the host is vulnerable. You should have received a ssl handshake failure if your host was patched. You should open a case with your vendor and as for a work-around or a patch.

R
RENEGOTIATING
140735200371552:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:615:

That is what you should have seen.

Aaron
  • 2,859
  • 2
  • 12
  • 30
  • yes, but from what I have read there is more to it than that for the server / device to actually be vulnerable. The SSL implementation could allow for the attack, but that does not necessarily mean that the end-point is vulnerable. See http://www.g-sec.lu/practicaltls.pdf (p. 24, "Vulnerability Requirements"): "The server treats both sessions as one and merges them at the application layer" The fact that the server is not delivering any data seems to indicate that it is not vulnerable. Do you agree? – Jim Balo Jan 05 '15 at 21:09
  • I would be speculating at this point. I would get the official answer from your vendor and document it internally so that you are covered. – Aaron Jan 05 '15 at 21:21
  • I dug deeper into one of the supposed vulnerabilities (vCenter), and despite responding to the openssl test above, it is not vulnerable: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016357 The more I dig into this, the more I am becoming convinced that my test above indicates that the device / server is NOT vulnerable, since the end point is not allowing the two sessions to be merged. – Jim Balo Jan 05 '15 at 21:22
  • There are two kinds of renegotiation: the original insecure one, and the fixed rfc5746 one; if 5746 is implemented, which `s_client` tells you in the snipped part, R->RENEGOTIATING is safe. @Jim: if the stack allows non-5746 renegotiation, the server is vulnerable if it *receives* data and *uses* the security parameters of the handshake particularly client-certificate; what the server *sends* doesn't matter in itself. – dave_thompson_085 Jan 28 '15 at 10:40