2

We did a Qualys test on two of our URLs earlier today. The URLs are of two similar applications (same versions) hosted on identical servers located at two different datacenters. The test returned 'A-' for one and 'F' for the other. The reason for 'F' rating was given as:

This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.

However, the version of OpenSSL we have on both the servers are old and identical:

[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

Why did the Qualys test not identify the vulnerability on the server that it gave 'A-' though it is running a vulnerable version of OpenSSL as the other? Is OpenSSL Padding Oracle vulnerability something that can be fixed at the firewall level? I suspect the firewall at the server that received the 'A-' was successful in filtering out the packet that was trying to test this vulnerability. Am I right? Is this something that can be fixed at the firewall level? (Since both the webservers are located at different data-centers and behind different firewalls)

Improve this question
2
  • maybe one server has an oracle patch that the other one doesn't.
    – cybernard
    Mar 13, 2017 at 13:29
  • Both has the same un-patched OpenSSL package.
    – Sreeraj
    Mar 16, 2017 at 12:31

1 Answer 1

Reset to default
4

Is OpenSSL Padding Oracle vulnerability something that can be fixed at the firewall level? I suspect the firewall at the server that received the 'A-' was successful in filtering out the packet that was trying to test this vulnerability. Am I right? Is this something that can be fixed at the firewall level?

No. SSL/TLS protocols have anti-tampering protections; if, for example, the firewall were to alter any of the handshake, the handshake would fail because both sides validate that what they sent was what got seen by the other side.

Other configurations might protect you. If you had a SSL offloader or man-in-the-middle proxy, something which terminated and then re-opened connections so that you have connections #1 and #2:

[Server]<---1--->[Proxy]<---2--->[Scanner]

Then that would do it, because the vulnerable SSL library on Server isn't being touched by the scanner.

However, the version of OpenSSL we have on both the servers are old and identical:

[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

And old. That version is superseded by openssl-1.0.1e-48.el6_8.4.x86_64.rpm. I would recommend updating it in both places and seeing if that makes it go away. Restart your services after updating, of course.

Notice that I haven't really addressed the root question of "Why do two servers with the same libraries give different results." That's because there's not really enough information to tell. Are the server daemons the same on both hosts? Could one be using different SSL libraries? Did the scanner exercise the same level of testing against both? How many times have you scanned each host? Are the results solidly consistent?

With all that unknown, and given that you're running a known deprecated version of OpenSSL, my recommendation is to patch and test again.

Improve this answer
6
  • Thank you. We definitely have decided to patch it, but I am trying to understand what is happening here. If I understood you correctly, then it could be the load-balancers too that is giving different results. Like, the server that got the '-A' is behind a load-balancer that is not affected by this vulnerability and the server that got the 'F' has a load-balancer that is vulnerable?
    – Sreeraj
    Mar 13, 2017 at 16:34
  • @Sreeraj yes, if you have something like an F5 load balancer and are using their LTM to terminate the SSL connection, then that's where you should look for the source of the finding.
    – gowenfawr
    Mar 13, 2017 at 16:38
  • Hypothetical question: If I am able to get the datacenter guys match the load-balancer settings of 'F' server with that of the '-A' server, then can I consider the vulnerability fixed, since this vulnerability won't cross over to the internet after the change?
    – Sreeraj
    Mar 13, 2017 at 16:50
  • 1
    16-2107 is on data not handshake; SSL/TLS protects both (differently) against tampering by firewall etc. Apparently this case is actually loadbalancers not servers using openssl, but if it were the servers it could be one server allowing only GCM versus another allowing CBC; if so that would be obvious in the SSLLabs reports.
    – dave_thompson_085
    Mar 13, 2017 at 18:00
  • @dave_thompson_085 thanks for keeping me honest, I lazily chose to describe handshake tampering even though it didn't apply to 16-2017 because it's easier to describe short of hand-wavy "because, encryption."
    – gowenfawr
    Mar 13, 2017 at 18:02

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.